- From: 陈智昌 <willchan@chromium.org>
- Date: Sat, 20 Apr 2013 13:51:09 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Jeff Pinner <jpinner@twitter.com>
Received on Saturday, 20 April 2013 20:51:41 UTC
+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 20:51:41 UTC