Making extensibility cheap

I've been somewhat convinced by Mike Bishop's arguments for restoring
extensibility[1].

What I find hard to swallow is the associated cost.  I think that
Mike's proposal could be trimmed further.  So I'm going to take up the
challenge.

Here's what I think we absolutely need:

1. A way to negotiate the use of hop-by-hop extensions.
2. A way to carry end-to-end extensions.
3. Extensibility for settings, frames and error codes.

To that end, here's my proposed reduction, which I think is largely
keeping with the spirit of Mike's draft:

Extensibility

As Mike suggests, we can open a few IANA registries for business.
That's text we can restore from old drafts.  Easy.

I agree that we need more space for settings than 8 bits, but I'm
going to be aggressive and suggest that 16 bits is enough.  We can
reserve some portion of that space for mucking around (a quarter is
what I'd suggest, but I don't care).

End-to-end

Here I'm going to suggest something far more limited than what Mike
does.  I think that we can get away with an end-to-end, flow
controlled, ordered frame.  A new frame type, modelled on Mike's
should work here.  The new frame type would include a 32-bit extension
ID, for which we can open a registry; we could piggyback on the PEN
registry (private enterprise number); or, we could recommend random
selection.  Again, I care not about these details and will go with
what people seem to like most.

We could do something more with optional flow control, optional
end-to-end and optional ordering, but I think that is altogether too
much optionality.

I'm aware that forcing flow control here might be controversial, but I
think that if we require intermediaries to forward this - and I think
we have to - this is the only good option.

Negotiation

I think that this doesn't need a new "EXTENSIONS" frame, I think that
we can use settings.  Each peer can set a setting to indicate that
they support feature X and if both support the feature, then the
state-affecting components of that feature can be activated.

Otherwise, all error codes map to INTERNAL_ERROR (or some new error
code we define that has equivalent semantics, i.e., none); all unknown
frame types are dropped; and all settings are ignored.

Note that this is important.  Unless you negotiate, only the special
"EXTENSION" frame will traverse intermediaries.

Advice Column

Mike's draft offers good guidance for extension designers.  I think we
need to crib some of that text.  Suggesting that an extension deal
with translating to and from HTTP/1.1, or dealing with peers that
don't support the extension is motherhood and apple pie.  More
important though is establishing the parameters for extension.  Much
of the above will need to reside in this section.

I am going to try to turn out some proposed text for this on the plane
tomorrow, in case this is what we decide to pursue.

--Martin

[1] in draft-bishop-http2-extension-frames

Received on Wednesday, 4 June 2014 00:00:58 UTC