- 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
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