- From: 陈智昌 <willchan@chromium.org>
- Date: Thu, 11 Oct 2012 10:43:50 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYixi6MD-0fLxeOtTA5Qfic9NiqDZY_OrtFdKids8osacQ@mail.gmail.com>
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 >
Received on Thursday, 11 October 2012 17:44:18 UTC