httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: mod_deflate DoS using HEAD
Date Wed, 15 Jul 2009 07:51:08 GMT
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 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)

Regards, Joe

Mime
View raw message