Re: Git Issues: PING

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 <jasnell@gmail.com> wrote:

> 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 (陈智昌)
> <willchan@chromium.org> wrote:
> > +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.
> >
> >
> > On Sat, Apr 20, 2013 at 12:37 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> 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
> >>
> >
>