> -----Original Message----- > From: Joe Orton [mailto:jor...@redhat.com] > Sent: Mittwoch, 15. Juli 2009 09:51 > To: dev@httpd.apache.org > Subject: Re: mod_deflate DoS using HEAD > > On Tue, Jul 14, 2009 at 05:47:16PM +0200, "Plüm, Rüdiger, > VF-Group" wrote: > > > > > > > -----Original Message----- > > > From: William A. Rowe, Jr. > > > Sent: Montag, 13. Juli 2009 23:58 > > > To: dev@httpd.apache.org > > > Subject: Re: mod_deflate DoS using HEAD > > > > > > Nick Kew wrote: > > > > Eric Covener wrote: > > > > > > > >> /* For a 304 response, only change the headers */ > > > >> - if (r->status == HTTP_NOT_MODIFIED) { > > > >> + if (r->status == HTTP_NOT_MODIFIED || > r->header_only) { > > > > > > > > Technically speaking, screws up the protocol. > > > > > > > > IMHO it would be acceptable provided: > > > > (a) it's an option for the admin, rather than enforced > > > > (b) it's documented > > > > (c) the headers are correct: either Content-Encoding is > > > > unset (uncompressed response) or Content-Length is > > > > unset. Probably the former. > > > > > > Agreed. It's not a DoS. If the admin wants to conserve CPU > > > resources, they must either; > > > > > > * cache the deflated pages (avoid user-agent header if there > > > are multiples, which reminds me we need a module to unset the > > > accept deflate trigger on non-compliant browsers running > > > very-first in the quick_handler.) > > > > > > * create gzip'ed content, navigate the choice of content through > > > multiviews. > > > > > > * do not do server-side deflation (it is expensive). > > > > > > > All very true. But how about the following patch. It should do no > > harm and should solve the issue in at least some cases (I think > > in most cases): > > I'm confused. Why do this check so late, and why does r->bytes_sent > matter? Why does it "screw up the protocol" if the DEFLATE
All depends on the first brigade that passes mod_deflate. If this brigade contains the whole response *and* mod_deflate can compress this response in one go meaning calling ap_passbrigade only once to sent the fully compressed response then the content-length filter can determine the length of the content and add it to the HEAD response as the same GET request would be delivered with a C-L. If the above is not true the according GET response would be delivered with T-E chunked anyway (in the HTTP/1.1 case or without anything but closing the connection after sending the response in the HTTP/1.0 case). So there is no point in doing further compression. And r->bytes_sent != 0 indicates that we have been already in the content length filter and that it cannot measure the length of the response for creating a C-L header as I tried to explain in my comment. Well one might argue that the number of cases where the first brigade contains the whole response *and* mod_deflate can compress this response in one go meaning calling ap_passbrigade only once to sent the fully compressed response is so low that this doesn't justify this approach and that we should just get out of the way in the case of HEAD requests. Especially as providing the correct C-L in a HEAD response is only a SHOULD (see below) > filter does > nothing for a HEAD request? Because of the concern that a HEAD will > return a different C-L & C-E to a GET on the same resource > with the same > Accept-Encoding header? Does 2616 mandate that a resource > must always > exactly the same set of content-codings across methods and time? > (AFAICT there is no MUST on that front; it's a SHOULD if anything) Exactly this is my impression and it is backed by 9.4 in RFC2616. But you are correct it is only a SHOULD. Regards Rüdiger
