W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: improved caching in HTTP: new draft

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Fri, 23 May 2014 09:46:46 +0000
To: Chris Drechsler <chris.drechsler@etit.tu-chemnitz.de>
cc: Guille -bisho- <bishillo@gmail.com>, ietf-http-wg@w3.org
Message-ID: <7574.1400838406@critter.freebsd.dk>
In message <537F016C.3030407@etit.tu-chemnitz.de>, Chris Drechsler writes:

>1) The Etag is only consistent within one domain. The SHA-256 hash value 
>in the Cache-NT header identifies the transfered representation 
>absolutely independent of the used URLs (and therefore across domains).

I don't think this would work as you suspect.

Case 1:  SHA-256 input is the body of the object.

That means you cannot generate this header until you have generated the
entire object, ruling out progressive and optimistic delivery.

It's also not enough I belive, you may need to stick some of the
HTTP headers into the hash too, to get the expected behaviour.

Transfer-encoding, Content-type ?

This may not matter in anybodys actual reality, but I think it would
violate some of the many decorative rococo features in the RFCs.

Case 2:  You allow the content owner to define what goes into the SHA256

Now you just lost the "globably unique" property because everybody
and his nephew are going to do use SHA256("FOOBAR" + URL) because
it's the cheapest.  A lot of them will not even understand why
"FOOBAR" would be necessary.

You need to construct the object identifier from a FQDN name and a
site-controlled nonce:

	Cache-Key: FQDN ":" <nonce_max_128_hex_chars>

Which FQDN the origin organization decides to use is entirely their
own choice, as long as it's theirs to control.  Likewise, the nonce
can be anything they care to use.

And that however opens the door wide to cache-poisoning, since you
cannot really check that the FQDN is legit, without starting some
kind of X.509 certificate song and dance...

I don't dispute the validity of the use-case you're trying to handle,
but I have a hard time seeing it pay off.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 23 May 2014 09:47:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC