RE: can h2 extension frames carry data?

Effectively, there are two types of extensions:

1.      Those that modify base semantics.  These have to be negotiated before use.

2.      Those that don’t modify base semantics.  These can be sent optimistically; if the peer doesn’t speak it, though, you’re wasting bytes.

For type #1, Matthew has raised the question of whether you need a second-line defense against someone who has negotiated in error.  In one of my original extension drafts, I used a larger space to identify extensions to reduce the odds of an accidental collision.  However, outside of experimental scenarios, I think we could reasonably assume that a peer negotiating a given extension either intends to support it or is somehow malicious.

Type #2 would benefit from a frame that effectively NACKs extension support; a smarter peer could quash these optimistic extensions for the remainder of the session.  However, having called out these two types of extensions, I don’t see this helping with #1.  It’s a related conversation, but not the same.

Matthew, random idea for your specific case….  There was a proposed extension a while ago for sending a hash of the content in one direction or the other.  If you really want a sentinel, you could require the client to return some very lightweight hash of the data, and error if it’s not received in a timely manner.  I don’t know that I’d recommend that, but it’s an option.

From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Tuesday, November 3, 2015 1:53 PM
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Subject: Re: can h2 extension frames carry data?



On 3 November 2015 at 14:04, Amos Jeffries <squid3@treenet.co.nz<mailto: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/