- From: James M Snell <jasnell@gmail.com>
- Date: Sat, 20 Apr 2013 14:56:10 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Jeff Pinner <jpinner@twitter.com>
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 >> >
Received on Saturday, 20 April 2013 21:56:57 UTC