Does anybody see a problem with changing mod_cache to not update the
stored headers when the request has max-age=0, the body turns out
not to be stale and the on-disk header hasn't expired?
The rationale behind this is that there are hordes of stupid "download
managers" that always issue thi
On Mon, May 21, 2007 4:49 pm, Niklas Edmundsson wrote:
> Does anybody see a problem with changing mod_cache to not update the
> stored headers when the request has max-age=0, the body turns out
> not to be stale and the on-disk header hasn't expired?
>
> The rationale behind this is that there are
On Mon, 21 May 2007, Graham Leggett wrote:
Since max-age=0 requests can't be fulfilled without revalidating the
object they don't benefit from this header rewrite, and requests with
max-age!=0 that can benefit from the header rewrite won't be affected
by this change.
Am I making sense? Have I m
On May 21, 2007, at 7:49 AM, Niklas Edmundsson wrote:
Does anybody see a problem with changing mod_cache to not update
the stored headers when the request has max-age=0, the body turns
out not to be stale and the on-disk header hasn't expired?
Yes, the problem is that it will break content m
On 05/21/2007 09:07 PM, Roy T. Fielding wrote:
>
> Why don't you just add an ignore of cache-control on requests from
> those stupid download managers? A simple BrowserMatch should do.
I am not quite sure what you mean by this. AFAIK you cannot set
CacheIgnoreCacheControl based on env variabl
Niklas Edmundsson wrote:
At first glance, doing this I think will break RFC2616 compliance, and if
it does break RFC compliance then I think it should not be default
behaviour. However if it does solve a real problem for admins, then
having
a directive allowing the admin to enable this behavio
On May 21, 2007, at 2:22 PM, Ruediger Pluem wrote:
Why don't you just add an ignore of cache-control on requests from
those stupid download managers? A simple BrowserMatch should do.
I am not quite sure what you mean by this. AFAIK you cannot set
CacheIgnoreCacheControl based on env variables.
On Mon, 21 May 2007, Roy T. Fielding wrote:
On May 21, 2007, at 7:49 AM, Niklas Edmundsson wrote:
Does anybody see a problem with changing mod_cache to not update the stored
headers when the request has max-age=0, the body turns out not to be stale
and the on-disk header hasn't expired?
Yes,
tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson:
> -8<---
> Does anybody see a problem with changing mod_cache to not update the
> stored headers when the request has max-age=0, the body turns out not
> to be stale and the on-disk header hasn't expired?
> -8<--
On Tue, 22 May 2007, Henrik Nordstrom wrote:
tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson:
-8<---
Does anybody see a problem with changing mod_cache to not update the
stored headers when the request has max-age=0, the body turns out not
to be stale and the on-disk
On 5/24/07, Niklas Edmundsson <[EMAIL PROTECTED]> wrote:
On Tue, 22 May 2007, Henrik Nordstrom wrote:
> tis 2007-05-22 klockan 11:40 +0200 skrev Niklas Edmundsson:
>
>> -8<---
>> Does anybody see a problem with changing mod_cache to not update the
>> stored headers when the reque
On Thu, May 24, 2007 10:23 am, Sander Striker wrote:
>> > It's fine in an RFC point of view for the cache to completely ignore a
>> > 304 and not update the stored entity at all. But the response to this
>> > request should be the merge of the two responses assuming the
>> > conditional was added
On Thu, 24 May 2007, Sander Striker wrote:
>> -8<---
>> Does anybody see a problem with changing mod_cache to not update the
>> stored headers when the request has max-age=0, the body turns out not
>> to be stale and the on-disk header hasn't expired?
>> -8<---
>
tor 2007-05-24 klockan 13:22 +0200 skrev Niklas Edmundsson:
> c) RFC-wise it seems to me that a not-modified object is a
> not-modified object. There is no guarantee that next request will
> hit the same cache, so nothing can expect a max-age=0 request to
> force a cache to rewrite its
14 matches
Mail list logo
