Re: SPDY and the HTTP Binding

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

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

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?


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