- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 11 Aug 2010 08:16:21 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Wednesday, 11 August 2010 06:16:56 UTC