Re: improved caching in HTTP: new draft

In message <537F52B0.5080209@etit.tu-chemnitz.de>, Chris Drechsler writes:

>> 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 ?
>
>Why do you believe in this - can you explain it in more detail?

The way HTTP is defined, the headers are an unholy mix of transport
encapsulation and object metadata.  Some headers are both.

Although I have yet to see any non-contrived examples, there is
absolutely nothing preventing the exact same body from having
two entirely different meanings, depending on the headers.

For instance:
	Content-Encoding: gzip
	Content-Type: text/html
	<gzip'ed body>
vs.
	Content-Type: application/x-gzip
	<exact same gzip'ed body>
	
Are two very different responses for any sensible client, yet your
proposal would deliver either one for the other.

Just SHA256()'ing the body will not be enough to work with all the
pathological corner-cases inherent in HTTP's lack of architecture.

You could try to divine which headers you have to feed into the SHA256
to unravel the mess.  I wouldn't bother,

>As I see it: caching should/must ensure that the client will get exactly 
>what the origin server has sent.

Yes, *including* some of the headers under *certain* conditions.

>> Case 2:  You allow the content owner to define what goes into the SHA256
>> ------------------------------------------------------------------------
>
>No, I don't allow the content owner to define what goes into the SHA256. 
>It's clearly defined how the hash value should be computed.

And that doesn't work, see above.

And neither does case 2, as detailed in my previous email.


If the HTTPbis working group had as goal to make HTTP work better
than it does today, something like your proposal could have been
accomodated by eliminating some past mistakes, most notably
the mingling of transport/ metadata headers.

But given the WG's laser-like focus on compatibility with the limited
past, with almost no regard to the potentially infinite future,
your proposal is impossible to make work, and would just add to the
already overwhelming complexity of HTTP.

Poul-Henning

-- 
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 14:20:59 UTC