W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: I-D Action:draft-nottingham-http-pipeline-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 11 Aug 2010 17:29:32 +1000
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <66FA6E4A-EBE8-42A8-921A-D658440B1D0D@mnot.net>
To: Willy Tarreau <w@1wt.eu>
It's interesting, but it would require browsers to spew Req-MD5 headers into requests unconditionally... something that I can't imagine they're likely to want to do (especially at first, when adoption on the server side is low).

OTOH just doing the MD5 in the response is potentially interesting, although having the URI available in the response may be useful for other purposes (e.g., verifying that we're using the right URL for a base URI, etc.). As Martin pointed out, Content-Location could serve that purpose as well.


On 11/08/2010, at 4:16 PM, Willy Tarreau wrote:

> On Wed, Aug 11, 2010 at 03:19:15PM +1000, Mark Nottingham wrote:
>> Right. So generate Assoc-Req at the outermost reverse proxy; it's the device that's acting as the origin server in that interchange, after all.
> Well, in this case, it would be better to only transport an MD5 of the
> request. That would be a lot more scalable, a lot lighter for servers
> and reverse-proxies and cache friendly :
> Client:
>    GET http://example.com/foo1.css HTTP/1.1
>    Host: example.com
>    Req-MD5: 939caaf0a676b57a89429d5759834d21        (MD5 of "GET /foo1.css")
> Server:
>    HTTP/1.1 200 OK
>    Req-MD5: 939caaf0a676b57a89429d5759834d21        (copy of client's MD5)
> The advantage is that caches can cache this header just the same way
> as it would with Assoc-Req, but servers don't have to keep a copy of
> the full URI (which is variable-length) but instead just have to save
> 128 bits.  Also, it works well through reverse-proxies that rewrite
> requests because the client sends the MD5 of the request before it is
> mangled by reverse proxies.
> Also, servers don't have to emit the header if the clients don't emit
> it either.
> And I find it light in terms of bandwidth too.
> What do you think ?
> Regards,
> Willy

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 11 August 2010 07:29:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:54 UTC