RE: can h2 extension frames carry data?

The answer to your first question is clearly yes – provided the peers agree that a new alternative to the DATA frame exists before it actually goes on the wire, it’s perfectly valid.

Your latter question is a little more nuanced – what happens if two peers have different ideas of what a setting or frame type means?  Fundamentally, that’s why we have a registry of settings and frame types, of course, but there’s not a good way to determine that someone else has a bug there.

Other protocols have dealt with this by having a “mandatory to understand” bit on extensions, but that drags in other interop problems, and it still doesn’t help you in the case of a peer that thinks they understand, but are wrong.  I don’t see a good way to catch such an error, nor even a simple way we could have changed the protocol to make it detectable.  If a peer promises to support a feature but doesn’t, that’s a pretty fundamental brokenness.

Ultimately, I think we just trust in the uniqueness of values on the registry.  If someone seriously screws it up, they’ll find that they don’t have payload matching the Content-Length header they’ve received, and hopefully alarm at that point.  Not true of every request, but if you consistently have this bug, you should hit it quickly enough.

Is there value in a DROPPED_UNKNOWN_FRAME frame?

From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Monday, November 2, 2015 8:47 PM
To: ietf-http-wg@w3.org
Subject: can h2 extension frames carry data?

Hi folks, I have a simple question: can HTTP/2 extension frames be used to send data?

In draft-kerwin-http2-encoded-data I've defined the GZIPPED_DATA frame, which is just like DATA but gzipped. It's protected by a setting which defaults to 0, and you MUST NOT send a GZIPPED_DATA frame unless the peer's setting is 1.

The problem I'm facing is, what happens if a buggy peer sends the frame at the wrong time (or, potentially worse, if a buggy peer sends the setting incorrectly?) Because "implementations MUST discard frames that have unknown or unsupported types," we can end up silently losing data, with no way to detect it, let alone throw an error or recover.

In HTTP/2 we've been pretty good at backing up most MUST NOTs with detectable errors, and I don't feel comfortable introducing something where the "or else" is "the page you requested/sent evaporates silently."

Is this a deficiency of HTTP/2's extensibility model? Or am I missing a simple way to make it work?

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