Re: mod_deflate DoS using HEAD

2010-06-26 Thread Stefan Fritsch
On Tuesday 22 June 2010, Plüm, Rüdiger, VF-Group wrote: I am currently +0 on wether to use the patch above or my original proposal. Both have its pros and cons (Saving more CPU vs. be more picky about caching and implement an RFC SHOULD). I have now commited your original patch because it is

Re: mod_deflate DoS using HEAD

2010-06-22 Thread Ruediger Pluem
On 06/21/2010 11:37 PM, William A. Rowe Jr. wrote: On 6/21/2010 4:00 PM, Stefan Fritsch wrote: As I understand it, Rüdiger's patch may be better for caching but uses more CPU cycles. But it uses way less CPU than no patch at all. Therefore I propose to include that patch unless there is

Re: mod_deflate DoS using HEAD

2010-06-22 Thread Eric Covener
On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem rpl...@apache.org wrote: Does someone still have Eric's patch? Seems that I can't find it right now. This is what I have, but I never got off the fence back then much less now: Index: modules/filters/mod_deflate.c

RE: mod_deflate DoS using HEAD

2010-06-22 Thread Plüm, Rüdiger, VF-Group
-Original Message- From: Eric Covener Sent: Dienstag, 22. Juni 2010 15:33 To: dev@httpd.apache.org Subject: Re: mod_deflate DoS using HEAD On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem rpl...@apache.org wrote: Does someone still have Eric's patch? Seems that I can't

Re: mod_deflate DoS using HEAD

2010-06-21 Thread Stefan Fritsch
On Thursday 16 July 2009, William A. Rowe, Jr. wrote: Plüm, Rüdiger, VF-Group wrote: Good point. So your patch would invalidate a cached entity if the response to a GET delivered a C-L header, since HEAD and GET would deliver different C-L headers. OTOH I think only very small or

Re: mod_deflate DoS using HEAD

2010-06-21 Thread William A. Rowe Jr.
On 6/21/2010 4:00 PM, Stefan Fritsch wrote: As I understand it, Rüdiger's patch may be better for caching but uses more CPU cycles. But it uses way less CPU than no patch at all. Therefore I propose to include that patch unless there is clear consensus that Eric's patch is to be

Re: mod_deflate DoS using HEAD

2009-07-15 Thread Joe Orton
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

Re: mod_deflate DoS using HEAD

2009-07-15 Thread William A. Rowe, Jr.
Joe Orton wrote: 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

RE: mod_deflate DoS using HEAD

2009-07-15 Thread Plüm, Rüdiger, VF-Group
-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

Re: mod_deflate DoS using HEAD

2009-07-15 Thread Dan Poirier
William A. Rowe, Jr. wr...@rowe-clan.net writes: Joe Orton wrote: 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) Read through to the end, it breaks all

Re: mod_deflate DoS using HEAD

2009-07-15 Thread Joe Orton
On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote: 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

RE: mod_deflate DoS using HEAD

2009-07-15 Thread Plüm, Rüdiger, VF-Group
-Original Message- From: Joe Orton [mailto:jor...@redhat.com] Sent: Mittwoch, 15. Juli 2009 15:29 To: dev@httpd.apache.org Subject: Re: mod_deflate DoS using HEAD On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote: I'm confused. Why do this check so

Re: mod_deflate DoS using HEAD

2009-07-15 Thread Greg Ames
On Tue, Jul 14, 2009 at 11:47 AM, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: 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): Index: modules/filters/mod_deflate.c +if

Re: mod_deflate DoS using HEAD

2009-07-15 Thread William A. Rowe, Jr.
Joe Orton wrote: On Wed, Jul 15, 2009 at 11:03:24AM +0200, Plüm, Rüdiger, VF-Group wrote: 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

Re: mod_deflate DoS using HEAD

2009-07-15 Thread Nick Kew
William A. Rowe, Jr. wrote: So +1 to the proposed patch; in fact, +1 on unsetting C-L and treating HEAD to the same processing as 304. +1. Since it's a SHOULD not a MUST, we can be pragmatic with the headers. That's back to Eric's original patch, isn't it? -- Nick Kew

RE: mod_deflate DoS using HEAD

2009-07-14 Thread Plüm, Rüdiger, VF-Group
-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

Re: mod_deflate DoS using HEAD

2009-07-14 Thread William A. Rowe, Jr.
Plüm, Rüdiger, VF-Group wrote: +/* + * Optimization: If we are a HEAD request and bytes_sent is not zero + * it means that we have passed the content-length filter once and + * have more data to sent. This means that the content-length filter + *

Re: mod_deflate DoS using HEAD

2009-07-14 Thread Nick Kew
William A. Rowe, Jr. wrote: Plüm, Rüdiger, VF-Group wrote: +/* + * Optimization: If we are a HEAD request and bytes_sent is not zero + * it means that we have passed the content-length filter once and + * have more data to sent. This means that the

Re: mod_deflate DoS using HEAD

2009-07-14 Thread Nick Kew
Nick Kew wrote: The content-length could've been set anyway - the simplest case being a static file that's been stated. Have we definitely unset it? D'oh. Of course we have. Is this really an optimization? Sounds like correctness :) And do we want to also validate that Accept-Encoding:

Re: mod_deflate DoS using HEAD

2009-07-14 Thread Roy T. Fielding
On Jul 14, 2009, at 10:02 AM, Nick Kew wrote: That, on the other hand, stands. In the case of an HTTP/1.0 request, we'd be closing the connection to signal end-of-response. Not on a HEAD request. Roy

Re: mod_deflate DoS using HEAD

2009-07-14 Thread William A. Rowe, Jr.
Roy T. Fielding wrote: On Jul 14, 2009, at 10:02 AM, Nick Kew wrote: That, on the other hand, stands. In the case of an HTTP/1.0 request, we'd be closing the connection to signal end-of-response. Not on a HEAD request. But on the GET request with the deflate filter installed, we would not

Re: mod_deflate DoS using HEAD

2009-07-13 Thread Nick Kew
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

Re: mod_deflate DoS using HEAD

2009-07-13 Thread William A. Rowe, Jr.
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

Re: mod_deflate DoS using HEAD

2009-07-13 Thread William A. Rowe, Jr.
William A. Rowe, Jr. wrote: * do not do server-side deflation (it is expensive). Whoops - forgot one more * do not do content deflation, only transfer deflation, which should not metered by the content-length, right?

Re: mod_deflate DoS

2009-07-03 Thread Joe Orton
On Sun, Jun 28, 2009 at 08:20:20PM +0200, Stefan Fritsch wrote: we have received a bug report [1] that a DoS is possible with mod_deflate since it does not stop to compress large files even after the network connection has been closed. This allows to use large amounts of CPU if there is a