W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: can h2 extension frames carry data?

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 3 Nov 2015 17:04:26 +1300
To: ietf-http-wg@w3.org
Message-ID: <5638324A.9050802@treenet.co.nz>
On 3/11/2015 9:27 a.m., Matthew Kerwin wrote:
> On 03/11/2015 2:24 AM, "Cory Benfield" wrote:
>>> On 2 Nov 2015, at 16:12, Mike Bishop wrote:
>>> Is there value in a DROPPED_UNKNOWN_FRAME frame?
>> I don’t think so. However, I *do* think there’d be value in a
> DROPPED_UNKNOWN_FRAME error code that can be sent on a RST_STREAM frame.
> This would allow us to say that implementations MAY send a RST_STREAM frame
> with that error code set if a frame is dropped.
> Actually, having it as an extension frame type makes sense, almost
> ironically, because it can be ignored itself if the original frame sender
> doesn't care that the original frame was dropped (as is the case with most
> meta extension frames, like in alt-svc.)
> I'd half considered the idea of a GZIPPED_DATA ACK signal, but I think a
> generic NAK makes more sense. If it were to be specified in a very simple
> extension of its own, with clear utility, it could stand a much higher
> chance of being widely implemented.
> For a RST_STREAM to work, it probably should be baked into h2 itself;
> otherwise you roll a die everytime you send extensions to a peer (will they
> silently drop it, or loudly fail?)

No you don't. When the peer does not also send the same extension in its
SETTINGS, or does not ACK it (depending on what the extension requires).
Then it does not support that extension.

Sending extension frames without explicitly knowing the peer can accept
them is *your* implementation being broken. At the very least it will be
wasting bandwidth and time. At worst it will be screwing up
transactions. Neither is good.

Received on Tuesday, 3 November 2015 04:05:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC