W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Git Issues: PING

From: James M Snell <jasnell@gmail.com>
Date: Sat, 20 Apr 2013 14:56:10 -0700
Message-ID: <CABP7RbcdGeBKfQke=NocROhow9kSuV4MOQvP4MMJrwzP7ip56Q@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC