Re: Should Web Services be served by a different HTTP n+1?

[William Chan (陈智昌) <[e-mail]>]

On Thu, Jan 24, 2013 at 9:49 AM, Phillip Hallam-Baker <[e-mail]> wrote:
>
>
> On Thu, Jan 24, 2013 at 12:34 PM, William Chan (陈智昌) <[e-mail]>
> wrote:
>>
>> I think SPDY is simpler for parsing headers in comparison to HTTP/1
>> except for the compression part. Would you agree? Patrick has written
>> up a good comparison here:
>>
>> http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html#c5703739431744738432.
>>
>> Can you clarify what exactly bothers you about piping your messages
>> through a compression library? There are clearly some concerns, but I
>> want to hear what specifically bothers you.
>
>
> The main one is that the receiver has to have enough memory to store the
> dictionary.

I think this boils down to the argument on the other thread. Do the
gains for keeping state outweigh the costs? Note that given Roberto's
delta compression proposal, the sender can disable compression
entirely, so the receiver does not need to maintain state. Browsers
probably would not do this, due to our desire to optimize for web
browsing speed. For web services where you control the client, you
indeed would be able to disable compression.

>
> That in turn means that the sender has to know whether the receiver has
> enough space which in turn means that they have to have some way of
> negotiating the dictionary size if the result is going to be reliable.
>
>
> As currently specified, SPDY makes no sense to me because the first step in
> SPDY is to essentially short circuit any intermediary or proxy by layering
> over SSL. So now we have a Web browser talking directly to the Web Server.
> So

Just to be exact, SPDY does not mandate SSL. Current browsers that
support SPDY (Firefox and Chromium) only use it over SSL by default.

>
> 1) Every header that has to do with intermediaries just became irrelevant
> 2) There is no reason that the client should send cookies on any request
> after the first
> 3) The content preferences of a browser are unlikely to change either
>
> Seems to me like delta encoding of the header set and converting well known
> headers to tokens is all we need. Coap has already done this work.

Note that the SPDY4 proposal is to use delta encoding which should
look like http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-00.
And James has his
http://tools.ietf.org/html/draft-snell-httpbis-bohe-00 proposal for
optimizing the well known headers. Do you disagree with the direction
here?

>
>
> --
> Website: http://hallambaker.com/