Re: SPDY and the HTTP Binding

On Thu, Oct 11, 2012 at 10:43 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

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

Granted. However, it makes very little sense to have three separate version
identification mechanisms (at the TLS-NPN level, the SYN_STREAM version
field, and the :version header).


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

Granted. However, the difference really boils down to only a single
additional byte. Surely that single byte wouldn't be too difficult to
ignore in non-http cases.


> * Roberto's proposing a new name/value header block anyway.
>

Looking forward to seeing his suggested changes.

- James


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