Subject: http/2 and "extensions"

From: James M Snell <[email-masked]>
Date: Tue, 15 Jul 2014 10:41:57 -0700

I really haven't had the opportunity to go through an read all of the
messages to understand the full context or what's actually being
written into the spec so I want to make sure... I'm seeing quite a few
comments passing by about pushing things into http/2 "extensions".
While having a clear, well-defined extensibility model in HTTP/2 is a
good thing. extensions themselves are a certainly a double-edged sword
if not handled appropriately. There are generally two points of view:

1. Extensions are good because they allow the protocol to evolve and
grow to meet new demands over time.

and

2. Extensions are bad because they give vendors excuses to not
implement functionality they disagree with. I.e. "We don't actually
want to do it that way, so we're going to pretend to be 'open' and
'encouraging' by saying that can be an "extension" when what we're
really going to do is kill it off by not implementing it".

So the question is: in HTTP/2, are there going to be clear notions of
mandatory-to-implement-but-not-mandatory-to-use extensions or are all
extensions going to be optional-to-implement. The difference is
critical. For example: I typically do not spend my time building
HTTP/2 infrastructure; I do, however, build applications on top of
HTTP/2 infrastructure. And if one of my applications depends on the
ability to use a particular HTTP/2 extension, I want to be clear on
whether or not I can rely on that extension being implemented or not.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 10:54:38 -0700

On 15 July 2014 10:41, James M Snell <[email-masked]> wrote:
> all extensions going to be optional-to-implement[?]

all extensions ARE going to be optional-to-implement.

You can't rely on other implementations supporting something that they
don't know about.  The extensibility features of HTTP (header fields,
content types) are available if you want something end-to-end.

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Jul 2014 11:01:59 -0700

Certainly extensions that come in the future would be
optional-to-implement, however, the question is directed more towards
the group of things being discussed today as "extensions"... the set
of things we already know about and are discussing. For example,
suppose we decide now that jumbo frames ought to be an extension. We
could choose to define those as either optional-to-implement (in which
case, they likely won't be implemented consistently) or
mandatory-to-implement-but-optional-to-use. I mainly want to make sure
that when people here say things like "Oh, we can do N as an
extension" that doesn't really mean, "Let's kill N because we don't
like it".

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 11:04:59 -0700

On 15 July 2014 11:01, James M Snell <[email-masked]> wrote:
> of things we already know about and are discussing.

Implicit in any discussion of making anything an extension is that it
is optional-to-implement.

Surely you can reach your own conclusions on what is implied by
suggesting that something be made an extension.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 16 Jul 2014 07:46:17 +1000

> is optional-to-implement.
The corollary​ to this is that extension authors have to consider, and
probably explicitly code into their extensions, how to deal with the
inevitable failure modes.

My feeling, coming from my encoded data thing, is that the more "real" the
extension (i.e. not just communicating nice-to-know metadata, but actually
doing something semantic), the more design and text is going to be
dedicated to dealing with unsupportive or broken peers.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 14:48:05 -0700

On 15 July 2014 14:46, Matthew Kerwin <[email-masked]> wrote:
> doing something semantic), the more design and text is going to be dedicated
> to dealing with unsupportive or broken peers.

Which leads back to a preference for a new protocol label at that point.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 16 Jul 2014 08:15:52 +1000

On 16 July 2014 07:48, Martin Thomson <[email-masked]> wrote:

> dedicated

Indeed, but that's a big wager for something potentially marginal. For a
single extension the technical difference is really only: in the one case,
just send the introductory frame/settings/etc. and see if it comes back; in
the other, negotiate on the token. Either way you learn whether or not it's
safe to use, and thereafter the logic in the code isn't that different.
However there's a bit of non-technical difference, in that supporting this
whole new "h2-zip" protocol just for a single flag in a DATA frame may seem
disproportionate and scary.

The real issue is multiple extensions, which we've said all along. If I
write encoded data, and someone else writes an awesome new header
extension, say, then which (if any) gets to have a protocol token? Do we
make three tokens for the two extensions? Dragons, etc. So I think we have
to write the extensions, do all the extra work to deal with the jagged
edges, and maybe one day they get to be coded into a new protocol.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 16 Jul 2014 06:23:52 +0000

In message <CABkgnnXxXUqSmXzQ_2VE5==[email-masked]>, Martin Thomson w
>Which leads back to a preference for a new protocol label at that point.

What makes you think that broken proxies will not be broken in this aspect also ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 10:10:51 -0700

> What makes you think that broken proxies will not be broken in this aspect also ?

I'm not suffering any delusions regarding mankind's ability to
generate better idiots, if that's what you are asking.  I think that
Matthew summarized the trade-offs here adequately.