- From: Matthew Kerwin <matthew@kerwin.net.au>
- Date: Tue, 3 Nov 2015 06:27:20 +1000
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, ietf-http-wg@w3.org
- Message-ID: <CACweHNBiF+W20KE-qV9TsO9mGbMTZ_7ViUdV-BBqfBz5AS7iOg@mail.gmail.com>
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> 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?) > 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. Cheers
Received on Monday, 2 November 2015 20:27:51 UTC