Re: SPDY and the HTTP Binding

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/