Re: HTTP2 Expression of Interest

On Sat, Jul 14, 2012 at 11:35 PM, Willy Tarreau <w@1wt.eu> wrote:

> [snip]
>
> > The use of a registry for well-known header field names would allow
> > for compact encoding of those names, but we foresee interoperability
> > problems as new fields are added.  A client will not be able to use
> > the assigned numeric code for a new field without knowing whether the
> > server also knows about it.
>
> It's just a matter of protocol versioning. We already have a registry of
> HTTP headers and it works well enough. An HTTP version would mandate one
> encoding and clients would respect this encoding. For tentatively new
> headers, they would be sent in clear text form until the connection
> suggests that the version is high enough to send them in raw form. Also,
> it has apparently worked well for WAP and I think that we could restart
> from this encoding instead of reinventing a fresh new one (maybe it needs
> a bit of refreshing though).
>
>
For the sake of discussion, use of a numeric code does not necessarily
introduce an interop challenge if must-ignore semantics are employed and
clearly spelled out. Assume, just for illustrative purposes, that we have
an IANA registry of headers. Each is assigned a numeric value and a code
page, represented by a single 16-bit integer. The first 4-bits represent
the code page, the remaining 12-bits represent the specific registered
header within the page. This should give us WAY more than enough room for
growth for new headers

 [0000] [0000 0000 0000]
  (CP)        (ID)

Let's also assume that the registrar is responsible for assigning the
specific ids to the header on a first-come-first-serve basis (unlike the
current scheme employed for status codes where spec authors just kind of
guess at one to use).

Now, let's say that code page 0 represents Registered "Must Understand"
headers. These are ones that tend to be critical to the basic operation of
the protocol, where failure to properly handle them could cause significant
issues. Code pages 1-9 represent registered "Must Ignore" headers... these
are ones that are known to be safe to ignore if they are not understood.
Code pages 10-15 are private use, with 10 being reserved for "Must
Understand" Private headers and the rest being must ignore. Everything in
the >= 10 range does not get registered, but applications would run the
risk of conflicts.

Suppose an application sends a message that contains a new CP#1 header that
the recipient does not understand. Seeing that it's CP#1, and seeing that
it's incapable of understanding the header, the server can reject the
message. However, suppose the application sends a message containing a new
CP#2-9 header or CP#11-15 header. If the server doesn't understand the new
header, it simply ignores it. If the application sends a new CP#10 header
that the server doesn't understand, the server rejects it.

Following such a scheme, clients or servers would be able to make use of
new header id's without having to know in advance if the header is
supported. There are, of course, a number of issues that could arise out of
this kind of scheme, but overall it should demonstrate that the use of
numeric codes does not necessarily impede interoperability.

The one significant area where it could fall apart is on
HTTP/2.0<==>HTTP/1.1 conversion, where the intermediary has to be able to
map the numeric identifiers to specific text labels. If the intermediary
sees a new CP#1 header that it doesn't understand and can't map, it would
have no choice but to return an error. If, however, it sees a header within
a must-ignore CP, and it's not able to map that header, it could either (a)
drop it silently or (b) provide some alternative generic encoding for that
header and let the recipient attempt to sort it out.

- James



> Best regards,
> Willy
>
>
>