You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ni...@apache.org on 2010/07/11 07:40:27 UTC
svn commit: r962985 - /httpd/httpd/branches/2.2.x/STATUS
Author: niq
Date: Sun Jul 11 05:40:27 2010
New Revision: 962985
URL: http://svn.apache.org/viewvc?rev=962985&view=rev
Log:
vote, comment, query
Modified:
httpd/httpd/branches/2.2.x/STATUS
Modified: httpd/httpd/branches/2.2.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=962985&r1=962984&r2=962985&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Sun Jul 11 05:40:27 2010
@@ -147,6 +147,16 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
mod_ldap directives under a virtualhost are sufficient to trigger this merge issue)
+1: covener, wrowe, trawick
+ *) mod_proxy_ajp: Ensure that we only return a non fatal error if the request
+ is idempotent and if we did not sent any request body so far.
+ Trunk version of patch:
+ http://svn.apache.org/viewvc?rev=955966&view=rev
+ Backport version for 2.2.x of patch:
+ Trunk version of patch works
+ +1: rpluem, trawick, niq
+ niq asks: did anyone check whether a similar change might be in order
+ in mod_proxy_http? Or any of the CGI implementations?
+
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
[ New proposals should be added at the end of the list ]
@@ -207,6 +217,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
Trunk patch: http://svn.apache.org/viewvc?rev=930125&view=rev
2.2.x patch: https://issues.apache.org/bugzilla/attachment.cgi?id=25153
Submitted by: Daniel Ruggeri <DRuggeri primary.net>
+ +1: niq
* mod_disk_cache: Decline the opportunity to cache if the response is
a 206 Partial Content. This stops a reverse proxied partial response
@@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
Trunk patch: http://svn.apache.org/viewvc?rev=951222&view=rev
2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch
+1: minfrin
+ niq asks: I can see the logic of not cacheing partial responses,
+ but why should mod_disk_cache worry about them if mod_cache allows
+ them, as in the following proposal?
*) mod_cache: Explicitly allow cache implementations to cache a 206 Partial
Response if they so choose to do so. Previously an attempt to cache a 206
@@ -223,14 +237,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
2.2.x Patch: http://people.apache.org/~minfrin/httpd-cache-partial2-2.2.patch
+1: minfrin
- *) mod_proxy_ajp: Ensure that we only return a non fatal error if the request
- is idempotent and if we did not sent any request body so far.
- Trunk version of patch:
- http://svn.apache.org/viewvc?rev=955966&view=rev
- Backport version for 2.2.x of patch:
- Trunk version of patch works
- +1: rpluem, trawick
-
*) mod_rewrite: Allow to set environment variables using mod_rewrite without
explicitely giving a value.
Most modules only check presence of a variable, not the value, so it makes
@@ -241,7 +247,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
http://svn.apache.org/viewvc?rev=960233&view=rev
Backport version for 2.2.x of patch:
http://people.apache.org/~rjung/patches/httpd-branch-2.2-mod_rewrite-env_var-emptyvalue.patch
- +1: rjung
+ +1: rjung, niq
*) mod_filter: enable filtering of errordocuments. PR 48377
http://svn.apache.org/viewvc?view=revision&revision=894041
Re: caching partial repsonses
Posted by Dan Poirier <po...@pobox.com>.
On 2010-09-02 at 12:37, Ruediger Pluem <rp...@apache.org> wrote:
> On 09/02/2010 04:09 PM, Dan Poirier wrote:
>> On 2010-07-11 at 01:40, niq@apache.org wrote:
>>
>>> Author: niq
>>> Date: Sun Jul 11 05:40:27 2010
>>> New Revision: 962985
>>>
>>> * mod_disk_cache: Decline the opportunity to cache if the response is
>>> a 206 Partial Content. This stops a reverse proxied partial response
>>> @@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>> Trunk patch: http://svn.apache.org/viewvc?rev=951222&view=rev
>>> 2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch
>>> +1: minfrin
>>> + niq asks: I can see the logic of not cacheing partial responses,
>>> + but why should mod_disk_cache worry about them if mod_cache allows
>>> + them, as in the following proposal?
>>>
>>> *) mod_cache: Explicitly allow cache implementations to cache a 206 Partial
>>> Response if they so choose to do so. Previously an attempt to cache a 206
>>
>> I think right now mod_cache doesn't let any 206 responses get to the
>> cache backends, but if that change is made to let them by, then backends
>> that don't correctly implement caching of 206 responses will need to
>> decline to cache them themselves.
>>
>> Which makes me wonder, won't other cache back-ends, like mod_mem_cache,
>> need the same change?
>
> Exactly, but mod_mem_cache is not on trunk any longer. So we cannot do
> a backport here, but must write a 2.2.x specific patch that is not on trunk.
True, but I think that's needed before we can backport the mod_cache
change being proposed here.
Dan
Re: caching partial repsonses
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/02/2010 04:09 PM, Dan Poirier wrote:
> On 2010-07-11 at 01:40, niq@apache.org wrote:
>
>> Author: niq
>> Date: Sun Jul 11 05:40:27 2010
>> New Revision: 962985
>>
>> * mod_disk_cache: Decline the opportunity to cache if the response is
>> a 206 Partial Content. This stops a reverse proxied partial response
>> @@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> Trunk patch: http://svn.apache.org/viewvc?rev=951222&view=rev
>> 2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch
>> +1: minfrin
>> + niq asks: I can see the logic of not cacheing partial responses,
>> + but why should mod_disk_cache worry about them if mod_cache allows
>> + them, as in the following proposal?
>>
>> *) mod_cache: Explicitly allow cache implementations to cache a 206 Partial
>> Response if they so choose to do so. Previously an attempt to cache a 206
>
> I think right now mod_cache doesn't let any 206 responses get to the
> cache backends, but if that change is made to let them by, then backends
> that don't correctly implement caching of 206 responses will need to
> decline to cache them themselves.
>
> Which makes me wonder, won't other cache back-ends, like mod_mem_cache,
> need the same change?
Exactly, but mod_mem_cache is not on trunk any longer. So we cannot do
a backport here, but must write a 2.2.x specific patch that is not on trunk.
Regards
Rüdiger
Re: caching partial repsonses
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/03/2010 02:13 AM, Graham Leggett wrote:
> On 03 Sep 2010, at 12:53 AM, Nick Kew wrote:
>
>> I disagree about 'broken': a cache isn't *required* to cache ranges.
>
> I definitely agree that a cache isn't required to cache ranges, but
> right now mod_cache actively forbids the caching of ranges by an
> implementation, and that's the behaviour that's currently broken.
>
>> As for third-party backends, this change is at serious risk of breaking
>> anything that has (perfectly reasonably) ignored range responses.
>> Fine for trunk, but not for a stable branch.
Good catch Nick.
>
> Good point, in that case I withdraw the backport, this makes sense.
But in this case we should backport
https://svn.apache.org/viewvc?view=revision&revision=933919
to fix PR49113, which would have been fixed by other means by Grahams
backport proposal.
Regards
Rüdiger
Re: caching partial repsonses
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Sep 2010, at 12:53 AM, Nick Kew wrote:
> I disagree about 'broken': a cache isn't *required* to cache ranges.
I definitely agree that a cache isn't required to cache ranges, but
right now mod_cache actively forbids the caching of ranges by an
implementation, and that's the behaviour that's currently broken.
> As for third-party backends, this change is at serious risk of
> breaking
> anything that has (perfectly reasonably) ignored range responses.
> Fine for trunk, but not for a stable branch.
Good point, in that case I withdraw the backport, this makes sense.
Regards,
Graham
--
Re: caching partial repsonses
Posted by Nick Kew <ni...@webthing.com>.
On 2 Sep 2010, at 18:20, Graham Leggett wrote:
> On 02 Sep 2010, at 7:01 PM, Nick Kew wrote:
>
>> Indeed. I guess my comment in STATUS was down to reviewing that
>> backport proposal (and checking the RFC) before I saw the other one.
>>
>> I guess the real question is: why enable it in the abstract, in the
>> absence of a backend implementation? Surely there's no backend
>> that's going to be simpler to support ranges in than plain ol' disk?
>
> mod_cache.h exports a public provider interface, allowing external parties to write implementations of their own that are distributed separately from the httpd server.
>
> It is broken for mod_cache to dictate to an external implementation that it is forbidden from caching partial responses, when the caching of partial responses is allowed by RFC2616.
I disagree about 'broken': a cache isn't *required* to cache ranges.
As for third-party backends, this change is at serious risk of breaking
anything that has (perfectly reasonably) ignored range responses.
Fine for trunk, but not for a stable branch.
--
Nick Kew
Re: caching partial repsonses
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Sep 2010, at 7:01 PM, Nick Kew wrote:
> Indeed. I guess my comment in STATUS was down to reviewing that
> backport proposal (and checking the RFC) before I saw the other one.
>
> I guess the real question is: why enable it in the abstract, in the
> absence of a backend implementation? Surely there's no backend
> that's going to be simpler to support ranges in than plain ol' disk?
mod_cache.h exports a public provider interface, allowing external
parties to write implementations of their own that are distributed
separately from the httpd server.
It is broken for mod_cache to dictate to an external implementation
that it is forbidden from caching partial responses, when the caching
of partial responses is allowed by RFC2616.
Regards,
Graham
--
Re: caching partial repsonses
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 02 Sep 2010 10:09:00 -0400
Dan Poirier <po...@pobox.com> wrote:
> I think right now mod_cache doesn't let any 206 responses get to the
> cache backends, but if that change is made to let them by, then backends
> that don't correctly implement caching of 206 responses will need to
> decline to cache them themselves.
Indeed. I guess my comment in STATUS was down to reviewing that
backport proposal (and checking the RFC) before I saw the other one.
I guess the real question is: why enable it in the abstract, in the
absence of a backend implementation? Surely there's no backend
that's going to be simpler to support ranges in than plain ol' disk?
--
Nick Kew
caching partial repsonses
Posted by Dan Poirier <po...@pobox.com>.
On 2010-07-11 at 01:40, niq@apache.org wrote:
> Author: niq
> Date: Sun Jul 11 05:40:27 2010
> New Revision: 962985
>
> * mod_disk_cache: Decline the opportunity to cache if the response is
> a 206 Partial Content. This stops a reverse proxied partial response
> @@ -214,6 +225,9 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> Trunk patch: http://svn.apache.org/viewvc?rev=951222&view=rev
> 2.2.x patch: http://people.apache.org/~minfrin/httpd-cache-partial-2.2.patch
> +1: minfrin
> + niq asks: I can see the logic of not cacheing partial responses,
> + but why should mod_disk_cache worry about them if mod_cache allows
> + them, as in the following proposal?
>
> *) mod_cache: Explicitly allow cache implementations to cache a 206 Partial
> Response if they so choose to do so. Previously an attempt to cache a 206
I think right now mod_cache doesn't let any 206 responses get to the
cache backends, but if that change is made to let them by, then backends
that don't correctly implement caching of 206 responses will need to
decline to cache them themselves.
Which makes me wonder, won't other cache back-ends, like mod_mem_cache,
need the same change?
Dan