Re: SETTINGS frames as header blocks?

On 14/04/2014 11:49 a.m., Alek Storm wrote:
> Hi all,
> 
> I have a radical suggestion for the SETTINGS frame: rather than serializing
> it as a sequence of (id, value) pairs, where id and value are 8- and 32-bit
> integers, respectively, use a header block, as in HEADERS/PUSH_PROMISE/
> CONTINUATION. This offers the following benefits:
> 
>    -
> 
>    Extensibility: By allowing setting names to be arbitrary strings, users
>    can introduce custom settings without worrying about collisions in a
>    255-element namespace, and without having to maintain some sort of registry.
>     -
> 
>    Expressiveness: String values allow complex settings to be encoded -
>    this has been widely, and successfully, used in HTTP headers (e.g. the Link
>    header <http://tools.ietf.org/html/rfc5988#section-5.5> and the
> cache-control
>    headers <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9>
>    ).

This point is a *downside* of textual representations. The purpose of
HTTP/2 is to rollout a fast and efficient binary protocol. The SETTINGS
frame is a mandatory to parse+process piece of that protocol.
 Forcing all implementations to contain a textual headers parser just
for SETTINGS re-introduces one of the major problems of HTTP/1 -
complexity and difficulty handling all possible textual input. Note the
original proposals for HTTP/2 were 2:1 against having HEADERS frames in
textual format as well.

>     -
> 
>    Simplicity: Making SETTINGS values more expressive would allow the new
>    ALTSVC frame to become a setting, rather than a separate frame, since it
>    confers only fire-and-forget connection-level metadata. In fact, it could
>    follow the format of the Alt-Svc HTTP
> header<http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-01#section-3>.
>    Other extensions to the protocol can be added the same way, just as
>    Alt-Svc was added to HTTP/1.1 - in contrast, "extension" frame types are
>    a non-starter, since implementations are required to error out when
>    receiving an unrecognized frame type.

If the editors choose to make ALTSVC a SETTINGS field it would be *far*
simpler to define ALTSVC as a setting in the binary form with an opaque
N-byte value following it. Textual SETTINGS content adds nothing but
complexity for this use-case.

> 
> There is also a semantic argument to be made: just as HEADERS frames
> express request/response-level metadata, SETTINGS frames express
> connection-level metadata (in fact, HTTP/1.1, which lacks the latter
> mechanism, has made use of header fields on individual requests to express
> properties about the connection as a whole, e.g. Alt-Svc and the hop-by-hop
> headers, like Connection and Upgrade).

HTTP/2 being binary protocol represents them as fixed binary fields in
appropriate places. Allowing simpler parsers with zero chance of parsing
errors from decoding text values into binary form - as seen routinely in
HTTP/1 traffic.

> 
> Adding header-table-size, enable-push, max-concurrent-streams, and
> initial-window-size to the initial static HPACK table (or even maintaining
> a separate compression context and static table) should allow us to achieve
> a final SETTINGS frame size comparable to the current serialization format.

Trading simplicity and speed which SETTINGS can be both created and
concumed for extra complexity and difficulty writing implementations.
While simultaneously increasing the state all implementations are
required to store long-term.

Also, your proposal earlier noted that complex and flexible textual
values would be a benefit. This contradicts the idea of having fixed
values in the static HPACK table. One cannot put textual names or values
that are unknown into the static HPACK table.


> I've been contributing to hyper <https://github.com/lukasa/hyper>, a Python
> client implementation, lately, and I'd be happy to give this proposal a
> whirl in a branch and report back with before-and-after benchmarks.
> 
> Apologies if the above has been proposed before - I wasn't able to find
> anything in a search of the archives, but I may have missed something.
> 

FYI: In one of the original proposals (network-friendly draft) we
started with simply separating the HTTP/1 end-to-end an hop-by-hop
headers into two frame types equivalent to SETTINGS and HEADERS. It was
even then intended to convert to binary forms similar to what is seen in
SETTINGS for most of the reasons I mention above and probably a lot of
others.

Amos

Received on Monday, 14 April 2014 02:16:49 UTC