Subject: Git Issues: PING

From: James M Snell <[email-masked]>
Date: Sat, 20 Apr 2013 12:37:26 -0700

Per https://github.com/http2/http2-spec/issues/68 ...

The question is: "In the current draft, the PING frame requires the
server to resend an arbitrarily large payload.... Perhaps restrict the
length of the PING frame to 0, allow any stream identifier in the
header require the server to echo the identifier? ... I'm not sure
what benefit being able to echo arbitrary contents provides."

Placing a cap on the size of the Ping payload makes sense. Whether
that cap should be strictly mandated by the spec or established via
SETTINGS is an open question, however. Perhaps the spec ought to place
a strict upper limit and allow recipients to optionally specify a more
restrictive value via SETTINGS?

- James

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 20 Apr 2013 13:51:09 -0700

+jpinner who filed the issue

Unless anyone comes up with a motivating reason to add arbitrary payloads,
let's just disallow them. This is what the SPDY/2 spec originally did (
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-PING):
"Length: This frame is always 4 bytes long."

Unless I missed a PING discussion elsewhere, it looks refactoring
accidentally introduced a semantic change. Let's fix that.

---

From: James M Snell <[email-masked]>
Date: Sat, 20 Apr 2013 14:56:10 -0700

The main argument I've seen for allowing a payload is so that the PING
sender can include a stronger correlation token than just the ID (a
timestamp, for instance).

On Sat, Apr 20, 2013 at 1:51 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> let's just disallow them. This is what the SPDY/2 spec originally did
> (http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-PING):

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 22 Apr 2013 12:43:58 -0700

I would be cautious of giving semantic meaning to the payload, and an ID
larger than 4 bytes seems unnecessary.

I do like the introduction of the PONG flag and the subsequent removal of
the restrictions on the ID field, letting the peer send whatever index into
their stored context that they like.

On Sat, Apr 20, 2013 at 2:56 PM, James M Snell <[email-masked]> wrote:

> > (