httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Wed, 20 Sep 2006 21:19:54 GMT

Ruediger Pluem wrote:
> On 09/20/2006 09:59 PM, Issac Goldstand wrote:
>> Ruediger Pluem wrote:
>>> First of all I guess you mean: BEFORE the CACHE_SAVE filter :-).
>>> Yes, there is a reason why we cannot do this: This would create a possible DoS,
because we have to
>>> suck in the whole response first before actually forwarding it. Also this would
not work with flush
>>> buckets.
>> Well, yes.  I stuck de-chunk in there as an afterthought (the original
>> check just being a sanity check on the reported entity size to take care
>> of that 0 length case).
>> Why the DoS, though?  No reason to suck everything in first - my thought
> I thought you wanted to use this as a prevention for the possible DoS that is prevented
> CacheMaxFileSize.
>> was to update the headers a second time after the body was written.
>> Only thing we need to hang on to is byte count and status (eg, headers
> I am not sure if its allowed for the cache to change the transport encoding. If yes
> I guess this makes sense.

I don't think it says one way or another straight-out.

The only really relevant line I saw (in a quick 15 minute review) is RFC
2616-3.6 (regarding transfer-encodings):
   "Transfer-coding values are used to indicate an encoding
   transformation that has been, can be, or may need to be applied to an
   entity-body in order to ensure "safe transport" through the network.
   This differs from a content coding in that the transfer-coding is a
   property of the message, not of the original entity."

Based on that, it seems to be ok.  However, we'd have to remove strong
ETags as a side-effect if it was done (since strong ETags change when
entity headers change).  And move trailers into headers (another reason
to rewrite the headers file at the end).  And probably other things
which I'm not think of...

In any case, if we're proxying for an HTTP/1.0 client using HTTP/1.1
(too tired to check if mod_proxy preserves HTTP version - but will try
to check tomorrow if no one beats me to it), or even serving cached
content to a 1.0 client originally received by a 1.1 request, we'd have
to do all this even now, wouldn't we?


View raw message