Re: can h2 extension frames carry data?

On 3 November 2015 at 14:04, Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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.
>
>
​"​Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard frames
that have unknown or unsupported types.  This means that any of these
extension points can be safely used by extensions without prior
arrangement or negotiation." RFC 7540, Section 5.5.

So while it could be a buggy implementation's fault, it could also be that
the extension was just written that way. I can send some inconsequential
but interesting ​frame* whenever I like, and according to RFC 7540 that's
fine; but the proposed RST_STREAM means some recipients might throw an
error back at me. So I say again, for an error to work it should be baked
into h2 itself. Here and now, the horse has already bolted.

And yes, it is the buggy/broken implementations I'm concerned about. In
almost every other part of the protocol, if someone in the wild screws up
there's a red flag which we can use to enter an error state. If someone
screws up this particular extension, data just evaporates, and we have to
rely on other heuristics, like content-length mismatches (which only works
if there is a content-length header, and violates layering, etc.), to
detect it.

* e.g. ALTSVC

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/