Re: SPDY and the HTTP Binding

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