W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 24 Jan 2013 12:49:23 -0500
Message-ID: <CAMm+LwgqYmwomf_3XFmqkS9bLTCEAaTt=f9bFuqhTfFzjFk3AQ@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Greg Wilkins <gregw@intalio.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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/
Received on Thursday, 24 January 2013 17:49:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 17:49:55 GMT