Re: SPDY and the HTTP Binding

On Thu, Oct 11, 2012 at 2:18 PM, Roberto Peon <grmocg@gmail.com> wrote:

> The version field could/should be pulled out and a better way to express
> this determined.
> This was original conceived as a way to allow proxies to carry multiple
> different versions of SPDY simultaneously over the same connection (e.g. to
> a server from multiple clients), but I've seen no support for such a
> requirement in any real deployments yet, and it doesn't seem likely to
> change.
>
> I believe strongly that we don't want to corrupt the session-layer with
> bits from the application-semantic layer unless we're getting significant
> benefit from it.
> The benefit we get from encoding scheme in bits is relatively small, and
> very much not future proof-- We do send both HTTP and HTTPS over a single
> SPDY connection today, and hopefully won't be limited to just these as we
> don't know what the future will bring (e.g. upgrade to ws over stream?
> Change of some other property? I know I can't predict it).
>
>
There's only so much we can and should do when it comes to "future
proofing"... and dropping the :scheme for a secure-bit does not rule out
the possibility of supporting other things in the future... it merely takes
a currently unused bit that already exists in the current framing and
assigns a meaning to it. If someone comes along in the future and wishes to
layer some as-yet-undefined-and-currently-theoretical protocol on top of
http 2.0, then they can still do so using headers. Nothing I've suggested
interferes with that.


> Given the way the compressor that I've been working on works, the "http"
> and "https" schemes are already present in the initial compression seed,
> thus end up being encoded in very few bits. Since it is delta-encoded, it
> is also not mentioned again unless you change the scheme. This would likely
> end up using fewer bits than attempting to encode it in the session-level
> frames...
>

The less we need to compress the better, right? This reduces scheme and
method down to only 9 bits total and gives them a fixed location in the
syn_stream which makes processing much more efficient... e.g. we don't have
to go looking for them at arbitrary positions in an arbitrary bag of
headers.


>
> On the compression stuff-- I apologize for the delay in getting the
> compression spec out. If all people want is a description of the
> fundamentals, I can do that quickly. For now I've been concentrating on the
> 'working code' informing the specification, and so have been working to
> ensure that the final product isn't more complex than is really required.
>
> On that note, what is it that people want to see here w.r.t. the
> compression stuff?-- Something high-level quickly, or a functional spec
> proposal in 1-3 weeks?
>
>
Yes :-) ... that is, can we have both, please :-)


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