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

Re: SPDY Review

From: Martin Nilsson <nilsson@opera.com>
Date: Fri, 08 Jun 2012 18:27:51 +0200
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: ietf-http-wg@w3.org
Message-ID: <op.wfleop18iw9drz@riaa>
On Thu, 07 Jun 2012 21:10:27 +0200, William Chan (陈智昌)  
<willchan@chromium.org> wrote:

>>
>
> I think I agree with you, but this paragraph is a bit short and I wanted  
> to
> ask for a clarification. When you say data overhead, you're referring to
> the framing overhead, right? And when you say lower latency for high
> priority requests requires higher overhead, you in particular mean that  
> by
> choosing smaller frame sizes, you have more opportunity to interleave, at
> the cost of more framing overhead, right? If so, I agree.
>

Correct.

>>
>> 4.3. Specialized HTTP frames
>>
>>  For the common case of using SPDY as an HTTP substitute, create
>>  special frames to open HTTP request-response and HTTP push
>>  streams. This removes the need for explicit unidirectional flag and
>>  mandatory header values.
>>
>
> What do you mean by mandatory header values? Those are specific to HTTP
> over SPDY, right? I'm not convinced about the necessity of baking in HTTP
> assumptions into the core SPDY layer, rather than defining the mandatory
> headers at the HTTP layering over SPDY level.
>

The background for this suggestion is the assumption that HTTP will be a  
significant use case of SPDY that may be worth optimizing for, and that  
the current SPDY binary format isn't very size efficient. There were also  
some concerns about the generic approach to directionality, which no  
longer applies if that feature is being removed.

>
>> 4.4. Typed key-value pairs
>>
>>  Create a better structure for the key-value pair lists where it is
>>  possible to have binary values and typed values. The types can
>>  include binary string, integer and list. Standardize how all
>>  standard HTTP headers should be normalized and typed, including
>>  which ones are disallowed to be in lists of multiple values.
>
>
>>  Introduce a mechanism that allows headers to be properties of the
>>  stream, to be used internally in SPDY, and move optional parameters
>>
>
> Did you mean properties of the session? Headers are already metadata for
> the stream.

This is a request for separation between SPDY specific stream headers  
(priority, slot and associate-to-stream-id given as examples) and HTTP  
(stream) headers.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Friday, 8 June 2012 16:28:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 June 2012 16:28:29 GMT