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

Re: can h2 extension frames carry data?

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Tue, 3 Nov 2015 06:27:20 +1000
Message-ID: <CACweHNBiF+W20KE-qV9TsO9mGbMTZ_7ViUdV-BBqfBz5AS7iOg@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, ietf-http-wg@w3.org
On 03/11/2015 2:24 AM, "Cory Benfield" <cory@lukasa.co.uk> wrote:
> > On 2 Nov 2015, at 16:12, Mike Bishop <Michael.Bishop@microsoft.com>
> > 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?)

> You could even go further and have a flag on frames that requires doing
that (a MUST_ERROR_IF_DROPPED flag, essentially). This allows for
implementations to say that certain extension frames are critical to
understand, and if you don’t understand them you need to let the other
implementation know.
> Of course, changing the frame header at this late stage is probably too
late, but in hindsight this seems like a nice thing to have had.

Yeah. I seem to recall that this was actually brought up at some point
while extensibility was being discussed -- possibly it was a frame id mask
rather than a flag, but same diff. The fact is it's not in h2, so we can't
rely on it; perhaps h3 will have it, but that depends on things like the
interop issues Mike mentioned.

Finally, Mike, thanks for pointing out that content-length might be useful
in detecting lost frames. I think there's something in that, which I can
write up.

Received on Monday, 2 November 2015 20:27:51 UTC

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