W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: SPDY and the HTTP Binding

From: Martin Nilsson <nilsson@opera.com>
Date: Thu, 11 Oct 2012 20:13:00 +0200
To: ietf-http-wg@w3.org
Message-ID: <op.wl00vyyhiw9drz@uranium.docomointertouch.net>
On Thu, 11 Oct 2012 20:01:56 +0200, James M Snell <jasnell@gmail.com>  
wrote:

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

I would expect to see this part completely reworked, since there are both  
syntactical and semantic issues with the current versioning system.

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

Looking at it in a more high level, I certainly makes sense to build in  
mandatory fields into a fix frame structure, both to save overhead and to  
simplify looking at only those fields. The real question is if non-HTTP  
should be possible in the HTTP/2.0 structure.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Thursday, 11 October 2012 18:13:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 11 October 2012 18:13:33 GMT