Ruediger Pluem wrote: > > On 09/20/2006 08:27 PM, Issac Goldstand wrote: >> Graham Leggett wrote: >> >>> On Wed, September 20, 2006 5:27 pm, Brian Akins wrote: >>> >>> >>>> unless 0 is a valid content-length, which it can be. Also, what about >>>> when we are reading something in without a know C-L, for example from an >>>> origin doing chunks? >>> I am not sure what the current cache code does to handle chunked entities >>> without a content length - in theory allowing the code to cache bodies of >>> no predetermined size leaves the cache open to a potential DoS. >>> > > You can set a max cache file size (CacheMaxFileSize) which prevents caching > files that are larger then > a specfic size. This is checked after each bucket is written to the disk. If > the > stream is larger then the max file size the file gets deleted and caching of > this request > is stopped. So this also works with chunked responses.
Yes - I didn't even consider this issue. > >> >> Nothing, IIRC. Any reason we can't add a C-L filter immediately after >> CACHE_SAVE to de-chunk and C-L it as needed? > > 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 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 ended, de-chunking state, etc). Ditto for flush buckets. What am I not considering? Issac
