I think your objections to using SSL are something I'm finding difficult to
understand. You don't like it that SSL cuts off man-in-the-middles?
SSL doesn't prevent a proxy, by the way, it simply requires that one is
configured explicitly instead of being implicit.
I'm also confused that you're advocating both keeping no state and keeping
state (e.g. cookies) at the same time?
-=R
On Thu, Jan 24, 2013 at 9:49 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:
>
>
> On Thu, Jan 24, 2013 at 12:34 PM, William Chan (陈智昌) <
> willchan@chromium.org> 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.
>
> 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
>
> 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.
>
>
> --
> Website: http://hallambaker.com/
>