W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: SPDY and the HTTP Binding

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Thu, 11 Oct 2012 10:43:50 -0700
Message-ID: <CAA4WUYixi6MD-0fLxeOtTA5Qfic9NiqDZY_OrtFdKids8osacQ@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I don't really care to dive into this level of detail in the framing yet,
since I feel like there are plenty of other contentious high level stuff
people we'll want to settle first. That said, I'll note a few things:
* The version field in SPDY isn't very well thought out, because we weren't
sure about how we were going to communicate the version. In practice, we
always rely on TLS-NPN, so this is kinda vestigial. Just FYI for the
history for it.
* Baking in those special headers into specific fields merges the HTTP
layer into the SPDY layer. Maybe that's the right way forward for HTTP/2.0,
but we have discussed other protocols layering on top of SPDY, for which
these HTTP specific fields would be undesirable.
* Roberto's proposing a new name/value header block anyway.

Meh. I figure we can optimize the framing after we've settled what features
we want.

On Thu, Oct 11, 2012 at 10:13 AM, James M Snell <jasnell@gmail.com> wrote:

> I've been going back through the HTTP binding described in the initial
> SPDY draft [1] and going through a variety of options for the header
> encoding and the thought struck me.. if headers such as :version, :method
> and :scheme are always going to be included in the SYN_STREAM, and these
> are always going to have fairly static and well defined values, there's
> really no reason at all why those should be encoded as headers in the first
> place -- let's just give them fixed positions within the SYN_STREAM block..
> [1] http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.1
> +------------------------------------+
> |1|    version    |         1        |
> +------------------------------------+
> |  Flags (8)  |  Length (24 bits)    |
> +------------------------------------+
> |X|           Stream-ID (31bits)     |
> +------------------------------------+
> |X| Associated-To-Stream-ID (31bits) |
> +------------------------------------+
> | Pri|S|Unused| Slot |M|             |
> +----------------------+             |
> | Number of Name/Value pairs (int32) |
> +------------------------------------+
> |     Length of name (int32)         |
> +------------------------------------+
> |           Name (string)            |
> +------------------------------------+
> |     Length of value  (int32)       |
> +------------------------------------+
> |          Value   (string)          |
> +------------------------------------+
> |           (repeats)                |
> For one, we already have the version field in the SYN_STREAM... we
> shouldn't need two separate protocol version identifiers within a single
> This would add one single-bit flag following the priority and one
> single-byte fields following the Slot.
> The single-bit field following the Priority would indicate whether or not
> the SYN_STREAM is secure... this is equivalent to sending
> ":scheme"="https". This would use up one fo the currently-unused 5-bits
> that exist after the priority. (I'm not even yet convinced that this flag
> is necessary at all. We might be able to drop the :scheme indicator
> completely).
> The one-byte field following Slot identifies the HTTP Method. Each method
> would be assigned a numeric identifier (GET=0x1, PUT=0x2, etc). New methods
> would be registered to get a new identifier (if a server gets a SYN_STREAM
> with an unknown method identifier it's no different than if they get a
> HTTP/1.1 request with an unknown method name).
> Using this approach, we eliminate three special case headers (":version",
> ":method" and ":scheme") and save at least around 31-bytes per SYN_STREAM.
>  - James
Received on Thursday, 11 October 2012 17:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC