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
