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
> -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
> wrote:
> > Does someone still have Eric's p
On Tue, Jun 22, 2010 at 2:37 AM, Ruediger Pluem 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
==
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
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 prefe
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
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 extremely compressable responses (whether
> static or not) wo
> -Original Message-
> From: Eric Covener
> Sent: Donnerstag, 16. Juli 2009 16:13
> To: dev@httpd.apache.org
> Subject: Re: mod_deflate DoS using HEAD
>
> On Wed, Jul 15, 2009 at 5:19 PM, Nick Kew wrote:
> > William A. Rowe, Jr. wrote:
> >
> >>
On Wed, Jul 15, 2009 at 5:19 PM, Nick Kew wrote:
> 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'
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
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 th
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
>
> +
> -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"
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
> cont
"William A. Rowe, Jr." 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 proxied co
> -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" wro
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
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
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 woul
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
Nick Kew wrote:
The content-length could've been set anyway - the simplest case being
a static file that's been "stat"ed. 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
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 content-lengt
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
> +
> -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, o
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?
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 accep
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 opti
27 matches
Mail list logo
