W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

SETTINGS frames as header blocks?

From: Alek Storm <alek.storm@gmail.com>
Date: Sun, 13 Apr 2014 16:49:14 -0700
Message-ID: <CAMNEcwt0ZdVz=sqW92iQAPFS_z+kW4aXDU0MiLDJ5=hccNYiGQ@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
   headers <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9>

   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
   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.

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).

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.
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.

Received on Sunday, 13 April 2014 23:49:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC