On 06 Sep 2010, at 11:00 PM, Paul Querna wrote:
Isn't this problem an artifact of how all bucket brigades work, and is
present in all output filter chains?
An output filter might be called multiple times, but a single bucket
can still contain a 4gb chunk easily.
It seems to me it would be
On Fri, 3 Sep 2010, Graham Leggett wrote:
snip
Regarding the issue of the disk cache cramming the entire file into
memory/address space, an alternate solution could be that the cache returns
buckets pointing to the cached file, ie that the cache consumed those pesky
mmapped buckets. This
cache while they are being cached. I don't know the
RFC implications of doing this, but in real life it's really useful.
With this in place, it becomes easy for an implementation to decide to
do in flight caching, plugging into the generic mod_cache provider
interface.
For those who have
On Mon, 6 Sep 2010, Graham Leggett wrote:
snip
For those who have forgotten, that's what we do in our
large-file-caching-patchset for mod_disk_cache (hidden as an attachment to
https://issues.apache.org/bugzilla/show_bug.cgi?id=39380 but I should
really get around to upload an up2date version
On 2010-09-06 at 05:52, Niklas Edmundsson ni...@acc.umu.se wrote:
On Fri, 3 Sep 2010, Graham Leggett wrote:
Been keen to do this for a while, this would definitely solve the
RAM problem, but wouldn't solve the time problem. Copying 4GB of
data from a slow disk can easily take minutes, and
Graham Leggett wrote:
Given that the make-cache-writes-atomic problem requires a change to
the data format, it may be useful to look at this now, before v2.4 is
baked, which will happen soon.
How much of a performance boost is the use-null-terminated-strings?
Regards,
Graham
--
If
On 06 Sep 2010, at 3:10 PM, Paul Fee wrote:
If mod_disk_cache's on disk format is changing, now may be an
opportunity to
investigate some options to improve performance of httpd as a
caching proxy.
Currently headers and data are in separate files. If they were in a
single
file, the
On Mon, 6 Sep 2010, Paul Fee wrote:
If mod_disk_cache's on disk format is changing, now may be an opportunity to
investigate some options to improve performance of httpd as a caching proxy.
Currently headers and data are in separate files. If they were in a single
file, the operating system
On Monday 06 September 2010, Paul Fee wrote:
Currently headers and data are in separate files. If they were in
a single file, the operating system is given more indication that
these two items are tightly coupled. For example, when the
headers are read in, the O/S can readahead and buffer
On Thu, Sep 2, 2010 at 10:16 AM, Graham Leggett minf...@sharp.fm wrote:
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r
On Thu, 2 Sep 2010, Graham Leggett wrote:
snip
Should however the cache implementation want to take a breath, it returns to
mod_cache with unconsumed bucket(s) still remaining in the in brigade.
mod_cache in turn sends the already-processed buckets in the out brigade
down the filter stack
covered separately in the email about atomic commits.
Also, if the client hangs up, will the cache impl get the chance to
finish its job (ie. completing the caching of a file instead of
starting over later on)?
That is a decision made by mod_cache itself, not the implementation
though
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade *b);
Right now, mod_cache expects a cache
On 09/02/2010 07:16 PM, Graham Leggett wrote:
Hi all,
An issue with mod_cache I would like to address this weekend is the
definition of the store_body() function in the cache implementation
provider:
apr_status_t (*store_body)(cache_handle_t *h, request_rec *r,
apr_bucket_brigade
Hi all,
A second issue I would like to attack this weekend is the issue of
atomic cache updates in mod_cache.
Right now today, two functions are provided to add and/or update a
cache entry:
apr_status_t (*store_headers)(cache_handle_t *h, request_rec *r,
cache_info *i
Hello Rüdiger,
Thank you for quick response and quick fix!
Regards,
Shibuya
-Original Message-
From: Plüm, Rüdiger, VF-Group [mailto:ruediger.pl...@vodafone.com]
Sent: Wednesday, April 14, 2010 5:58 PM
To: dev@httpd.apache.org
Subject: RE: Age calculation in mod_cache
Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Ryujiro Shibuya
Sent: Mittwoch, 14. April 2010 03:35
To: dev@httpd.apache.org
Subject: Age calculation in mod_cache.
Hello,
A minor issue in the age calculation in mod_cache
[ap_cache_current_age() in
cache_util.c
-Original Message-
From: Paul Fee
Sent: Donnerstag, 15. April 2010 15:43
To: dev@httpd.apache.org
Subject: RE: Age calculation in mod_cache.
Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Ryujiro Shibuya
Sent: Mittwoch, 14. April 2010 03:35
-Original Message-
From: Ryujiro Shibuya
Sent: Mittwoch, 14. April 2010 03:35
To: dev@httpd.apache.org
Subject: Age calculation in mod_cache.
Hello,
A minor issue in the age calculation in mod_cache
[ap_cache_current_age() in
cache_util.c] is found.
In some unusual
Hello,
A minor issue in the age calculation in mod_cache [ap_cache_current_age() in
cache_util.c] is found.
In some unusual conditions, the age of cached content can be calculated as
negative value.
The negative age value will be casted into a huge unsigned integer later
Summarizing, to reproduce this crash it is essential to:
1. Use a subrequest to generate contents for the URL which is
configured to be cached using mod_cache. While creating subrequest it is
essential to pass main request's output filters:
request_rec *rr = ap_sub_req_lookup_uri(/cache, r
On Sun, 10 Jan 2010, Graham Leggett wrote:
- In ap_cache_try_lock - do we really need the hashed directories
hardwired? I thought most modern filesystems had abandoned
linear search, so that kind of thing is redundant!
At least make it optional - perhaps an additional arg to
the Cachelock
On 2010/01/10 1:43 AM, Nick Kew wrote:
- In ap_cache_try_lock - do we really need the hashed directories
hardwired? I thought most modern filesystems had abandoned
linear search, so that kind of thing is redundant!
At least make it optional - perhaps an additional arg to
the Cachelock
I've just been attempting to review Graham's proposed backport.
Looks interesting, but just a few points:
Trivial: needs r809335.
Trivial: indentation doesn't quite fit code style guidelines.
- In ap_cache_try_lock - do we really need the hashed directories
hardwired? I thought most modern
this back to investigate as I have been ENOTIME, but I've noticed
a small detail:
Actually, this problem was traced to a bug in PHP's Apache filter. It
sets no_local_copy to 1 in its response to Apache, which denies
mod_cache from creating its own 304 Not Modified response code.
Etags
Nicholas Sherlock wrote:
If you make a conditional request for a cached document, but the
document is expired in the cache, mod_cache currently passes on the
conditional request to the backend. If the backend responds with a 304
Not Modified response that indicates that the cached copy
On 28 Aug 2009, at 06:13, toki...@aol.com wrote:
Brian Akins of Turner Broadcasting, Inc. wrote...
We are moving towards the 'if you say you support gzip,
then you get gzip' attitude.
The only approach that makes sense. Good to hear that from
folks as big as you.
There isn't a
MIME types.
That's a complete separate discussion and I'm not
goint to 'go there' tonight.
-Original Message-
From: William A. Rowe, Jr. wr...@rowe-clan.net
To: dev@httpd.apache.org dev@httpd.apache.org
Sent: Wed, Aug 26, 2009 1:47 pm
Subject: mod_cache, mod_deflate and Vary: User-Agent
On 8/26/09 3:20 PM, Paul Querna p...@querna.org wrote:
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice, instead of once for every user agent.
We do the same basic thing. We are moving
, Aug 27, 2009 9:42 am
Subject: Re: mod_cache, mod_deflate and Vary: User-Agent
On 8/26/09 3:20 PM, Paul Querna p...@querna.org wrote:
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice
* to determining the cache handling (quick handler hook) or
typical content handling.
Which implies that setenvif + headers need an extra chance to run really
first in front of the quick handler.
Any better suggestions?
Yes, write a Varied header to 'hash' plugin API for mod_cache.
I would
Paul Querna wrote:
Yes, write a Varied header to 'hash' plugin API for mod_cache.
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing in
mod_cache only twice, instead of once for every user agent.
This doesn't solve
On Wed, Aug 26, 2009 at 2:50 PM, William A. Rowe,
Jr.wr...@rowe-clan.net wrote:
Paul Querna wrote:
Yes, write a Varied header to 'hash' plugin API for mod_cache.
I would write little lua scriptlets that map user agents to two
buckets: supports gzip, doesnt support gzip. store the thing
Hi everyone,
If you make a conditional request for a cached document, but the
document is expired in the cache, mod_cache currently passes on the
conditional request to the backend. If the backend responds with a 304
Not Modified response that indicates that the cached copy is still up
Nicholas Sherlock n.sherl...@gmail.com writes:
If you make a conditional request for a cached document, but the
document is expired in the cache, mod_cache currently passes on the
conditional request to the backend. If the backend responds with a
304 Not Modified response that indicates
Dan Poirier wrote:
Nicholas Sherlock n.sherl...@gmail.com writes:
If you make a conditional request for a cached document, but the
document is expired in the cache, mod_cache currently passes on the
conditional request to the backend. If the backend responds with a
304 Not Modified response
Nicholas Sherlock wrote:
Thanks, I wasn't certain if the behaviour I wanted was HTTP-correct, but
it seems that it is (and anyway it'll save me on bandwidth costs, so I
really want to fix it). I'll go add it now.
This is now bug report #47580
Sorry to bother you all, and first: thanks for building such a great product!
My question is related to the patch suggested by Paul Quenna (in
2005) where mod_cache is allowed to be configured to run as a normal
handler instead of always as a quick handler.
The initial patch and related
Jon Grov wrote:
Our current workaround is to run two reverse proxy-instances, one which
provides authentication (on port 80) and another providing cache (on port
7920, which is only accessible from within PROXY). A request then
first hits the authentication proxy on port 80, and if valid, is
if one were to build a viewer, what sources should i take a look at?
would this be done at the module level or in httpd itself?
On Mon, Feb 9, 2009 at 11:17 AM, Eric Covener cove...@gmail.com wrote:
On Mon, Feb 9, 2009 at 1:54 PM, Matthew Sacks ntw...@gmail.com wrote:
Hi ASF,
Is there a way to
Alex Polvi wrote:
Hi there,
I ran into a weird case where *I think* mod_cache should be caching a
request that it is not. Thought I would try to fix it myself, but
would like to seek your feedback as it is my first httpd patch (thanks
to pquerna for the help/encouragement).
Caching a 302
I don't quite understand...
Niklas Edmundsson wrote:
The main problem with mod_limitipconn-0.22 was that since mod_cache runs
as a quick handler, mod_limitipconn also must run as a quick handler
with all those benefits and drawbacks.
... MIME types exempt from limit checking ...
hashes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
William A. Rowe, Jr. wrote:
We might not be able to do much about that anyways but it should probably
be documented that it doesn't limit connections or assist in preventing
DoS attacks.
Are you talking about mod_limitipconn? If you are, then
Arturo 'Buanzo' Busleiman wrote:
William A. Rowe, Jr. wrote:
We might not be able to do much about that anyways but it should probably
be documented that it doesn't limit connections or assist in preventing
DoS attacks.
Are you talking about mod_limitipconn? If you are, then rename it to
On Fri, 22 Aug 2008, William A. Rowe, Jr. wrote:
I don't quite understand...
Niklas Edmundsson wrote:
The main problem with mod_limitipconn-0.22 was that since mod_cache runs as
a quick handler, mod_limitipconn also must run as a quick handler with all
those benefits and drawbacks
Niklas Edmundsson wrote:
[...] are probably more content with this for now than having to wait
for someone committing the Perfecttm solution to httpd :)
Right; I'm not saying don't commit it (things can be fixed in trunk, that's
the point), but as you mentioned you want to get the naming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
William A. Rowe, Jr. wrote:
I'm pointing out this isn't a connection limit, it's a request limit, and
we should probably commit it with an appropriate module name :)
mod_req_limit or another variant thereof?
- --
Arturo Buanzo Busleiman
On Wed, Jun 18, 2008 at 6:30 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thats correct. This doesn't work. I guess the following patch might fix
this:
Index: modules/mappers/mod_dir.c
===
--- modules/mappers/mod_dir.c
Hi,
I think these questions are more appropriate to dev@ than users@,
sorry if I am wrong.
I'm using Apache 2.2.8 and have hit two snags concerning mod_dir.
Accessing http://localhost/ instead of http://localhost/index.html has
the following effects:
1) It bypasses mod_cache
effects:
1) It bypasses mod_cache (with mod_disk_cache as a backend).
Thats correct. This doesn't work. I guess the following patch might fix
this:
Index: modules/mappers/mod_dir.c
===
--- modules/mappers/mod_dir.c (Revision 669255
On Wed, Jun 18, 2008 at 6:30 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
Thats correct. This doesn't work. I guess the following patch might fix
this:
Thanks. I will try it out.
But since this might have remarkable side effects other should have a look
on this.
Should I open a bug?
The
On Wed, Jun 18, 2008 at 6:30 PM, Ruediger Pluem [EMAIL PROTECTED] wrote:
The transfer encoding has nothing to do with the question whether a
contents is cacheable or not. SSI content typically isn't cachable
because it unsets the Last-Modified header. See also
Adriano Nagel wrote:
On a side note, apparently SSI virtual includes don't pass through the
cache layer.
have you confirmed this against 2.2.9, which includes many changes to proxy?
William A. Rowe, Jr. wrote:
Adriano Nagel wrote:
On a side note, apparently SSI virtual includes don't pass through the
cache layer.
have you confirmed this against 2.2.9, which includes many changes to
proxy?
Nevermind, I see Rudiger's comments. Sounds like he may even be on to
the
Okay, started looking at mod_cache and had a question about the way it is
handling providers.
We call ap_cache_get_providers which seems to do a lot of work that we could
probably do at config time rather than run time. Any reason why providers
can't be attached to uri's at config time and avoid
| | PURGE http://cachehost/someuri HTTP/1.1
| |
|
| Isn't it better to do it as a uri - say - /cache-control - hosted on the
| proxy?
| so the above would look like
|
| POST /cache-control?purge
|
| http://cachehost/someuri1
| http://cachehost/someuri2
| http://cachehost/someuri3
|
|
|
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
WCIP/BEEP went nowhere afaict, but I want to keep things simple. The
way Squid handles this is by implementing a non-standard PURGE HTTP
method, so I've taken
On Fri, 30 May 2008, Colm MacC?rthaigh wrote:
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
Aye - common problem!.
PURGE /foo HTTP/1.1
..
While above is 'always' a good/sensible approach. I'd like
On Fri, May 30, 2008 at 10:35 AM, Dirk-Willem van Gulik
[EMAIL PROTECTED] wrote:
something more like mod_proxy_balancer's full-scale html interface for
doing this kind of thing at run-time?
No, totally nut - bot I am much more interested in a deeper, programmatic,
interface - which I can hook
On 05/30/2008 11:13 AM, Ruediger Pluem wrote:
On 05/30/2008 10:28 AM, Colm MacCárthaigh wrote:
For one reason or another, I need to be able to invalidate cache
entries in some mod_cache caches. There's no good standard for this,
WCIP/BEEP went nowhere afaict, but I want to keep things
[..]
| The patch actually works, you can call;
|
| PURGE /foo HTTP/1.1
| Host: example.org
| Accept: foo/bar
|
[..]
| the PURGE request. So sending a PURGE request to 127.0.0.1:8080 with the
| caching
| virtual host being 'cachehost' will look like:
|
| PURGE http://cachehost/someuri HTTP/1.1
On fre, 2008-05-30 at 11:06 +0200, Colm MacCárthaigh wrote:
Yep, Squid will delete all variations of an entity when you use
Accept: */*, that isn't easy with our current approach, but I'll see
what I can do - it would be nice.
Squid isn't quite that good on purging variants either..
Regards
On Fri, 30 May 2008, Ruediger Pluem wrote:
It would be also nice if the purge could be enabled only in a virtual host
different
..
PURGE http://cachehost/someuri HTTP/1.1
Would a normal Limit PURGE etc sort of thing on the Location not do this
? Or is location too path centric ?
Dw
On 05/30/2008 12:43 PM, Dirk-Willem van Gulik wrote:
On Fri, 30 May 2008, Ruediger Pluem wrote:
It would be also nice if the purge could be enabled only in a virtual
host different
..
PURGE http://cachehost/someuri HTTP/1.1
Would a normal Limit PURGE etc sort of thing on the Location
On 05/30/2008 11:39 AM, rahul wrote:
[..]
| The patch actually works, you can call;
|
| PURGE /foo HTTP/1.1
| Host: example.org
| Accept: foo/bar
|
[..]
| the PURGE request. So sending a PURGE request to 127.0.0.1:8080 with the
| caching
| virtual host being 'cachehost' will look like:
|
How we handle purge:
-Our cache is only disk based, so it is somewhat easier.
-We have a hook that gets called after each cache store - ie, after we write
a vary meta file, after we write a real meta file, after a datafile write
(on close).
-We also have a cache_get_info function that is exported
On Fri, May 30, 2008 at 1:59 PM, Akins, Brian [EMAIL PROTECTED] wrote:
How we handle purge:
Oh that reminds me, a long time ago, I wrote htcacheadmin - a generic
command line utility for administering mod_disk_cache caches. Which is
how I /used/ to handle this situation. (I've attached the
On 05/30/2008 05:14 PM, Colm MacCárthaigh wrote:
On Fri, May 30, 2008 at 1:59 PM, Akins, Brian [EMAIL PROTECTED] wrote:
How we handle purge:
Oh that reminds me, a long time ago, I wrote htcacheadmin - a generic
command line utility for administering mod_disk_cache caches. Which is
how I
What if Vary were much more than just HTTP Vary? It would be nice if the
framework could support the external vary (ie, normal HTTP Vary) as well
as any internal Vary.
To use general mod_disk_cache structure, we currently have something sorta
like this for vary metafiles:
int cache_version
Dirk-Willem van Gulik wrote:
There is a lot of valuable stuff in your jumbo patch - but I am not sure
what the best approach is to fold it in.
Could you have have a look at the rough patch I posted earlier today -
and let me know if you have any thoughts
as to which parts should be moved
On Fri, 9 May 2008, Graham Leggett wrote:
There is a lot of valuable stuff in your jumbo patch - but I am not sure
what the best approach is to fold it in.
Could you have have a look at the rough patch I posted earlier today - and
let me know if you have any thoughts
as to which parts should
Niklas Edmundsson wrote:
I'm not convinced that forking the disk cache having two similar ones
tuned for different usecases is a good idea in the long run, I'm pretty
sure that the parts that needs tweaking can be solved with config
options and documentation. For a development sprint like
William A. Rowe, Jr. wrote:
I think the bigger idea that mod_cache must handle all rfc related issues
is key. mem and disk cache should never have had substantial differences
in behavior, but they do.
So the more we can consolidate in mod_cache w.r.t. the requests themselves,
the less
Hi all!
Getting a few cycles I thought I should do an easy migration to httpd
2.2.8, but it seems that the thing is dumping core on me...
Are anyone else using httpd 2.2.8 together with mod_cache seeing this?
At the moment I'm not sure where the problem is. Our mod_disk_cache
patches
-Ursprüngliche Nachricht-
Von: Niklas Edmundsson
Gesendet: Mittwoch, 20. Februar 2008 11:40
An: dev@httpd.apache.org
Betreff: httpd 2.2.8 + mod_cache segfaults
Hi all!
Getting a few cycles I thought I should do an easy migration to httpd
2.2.8, but it seems
On Wed, 20 Feb 2008, Niklas Edmundsson wrote:
Getting a few cycles I thought I should do an easy migration to httpd
2.2.8, but it seems that the thing is dumping core on me...
Are anyone else using httpd 2.2.8 together with mod_cache seeing this?
At the moment I'm not sure where
On Wed, 20 Feb 2008, Plüm, Rüdiger, VF-Group wrote:
Anyone seen something similar? Any hints on where to dig?
From what I can see in the stack trace frame #4 points to the NULL pointer.
OK, I thought that one looked fishy ;)
Looks like there is no copy function set for the particular
an early processing for RequestHeader and modify
it removing spaces. My question is:
should mod_cache match Vary headers 'exactly' as they are or would it be
advisable to simply 'remove spaces' from it and then match so browser bugs
such as this won't cause cache misses?
-server.com/tutorials/ATdocs-project.html the
relevant docco-documentation? Should it be a combined patch with both
code and docs?
- What's the correct way of getting the mod_cache configuration from
the mod_disk_cache module?
Look inside mod_proxy_http.c for a function called
]
(the permalink doesn't seem to show the nifty thread list, you have to
click a bit for that).
What I'd like answered is:
- Was the latest patch as suggested OK?
- What's the correct way of getting the mod_cache configuration from
the mod_disk_cache module?
/Nikke
Niklas Edmundsson wrote:
What I'd like answered is:
- Was the latest patch as suggested OK?
The latest patch was the one with a directive, which is +1 from me -
though is it possible to add documentation for the directive?
- What's the correct way of getting the mod_cache configuration
On Tue, 31 Jul 2007, Niklas Edmundsson wrote:
Any opinions on this?
Here's a version with a config directive, defaults to disabled.
Silly Q; a directive? Or a env var that can be scoped in interesting
ways using mod_setenvif and/or mod_rewrite?
Most of our proxy behavior overrides are in
Hi,
I submitted a simple patch that fixes the above mentioned PR, and then some.
1. All of the Cache-Control request directives are ignored. As a consequence,
end-to-end reload is for example not possible. Originally
ap_cache_check_freshness() read the Cache-Control header from
On Tue, 31 Jul 2007, Sander Striker wrote:
Here's a version with a config directive, defaults to disabled.
Silly Q; a directive? Or a env var that can be scoped in interesting
ways using mod_setenvif and/or mod_rewrite?
Most of our proxy behavior overrides are in terms of envvars. They are
On Sun, 29 Jul 2007, Graham Leggett wrote:
What may make this workable is the combination of The body is NOT stale
with max-age=0. The danger of not writing the headers is that an entity,
once stale, will not be freshened when the spec says it should, and will
cause a thundering herd of
On Mon, July 30, 2007 10:40 am, Niklas Edmundsson wrote:
What may make this workable is the combination of The body is NOT
stale
with max-age=0. The danger of not writing the headers is that an
entity,
once stale, will not be freshened when the spec says it should, and will
cause a
On Sun, 29 Jul 2007, Roy T. Fielding wrote:
The solution is to NOT rewrite the on-disk headers when the following
conditions are true:
- The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating)
- The on-disk header hasn't expired.
- The request has max-age=0
This is perfectly OK with
On Mon, 30 Jul 2007, Niklas Edmundsson wrote:
However, if stuff is really depending on Date/Expires being what it thinks it
is (*shiver*) then I guess there won't be any other options...
Here's a version with a config directive, defaults to disabled.
Thoughts?
/Nikke
--
On 7/31/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Niklas Edmundsson wrote:
On Mon, 30 Jul 2007, Niklas Edmundsson wrote:
However, if stuff is really depending on Date/Expires being what it
thinks it is (*shiver*) then I guess there won't be any other options...
Here's a
Attached is a patch for mod_cache (patch is for httpd-2.2.4) that
implements what I suggested in May (see the entire thread at
http://mail-archives.apache.org/mod_mbox/httpd-dev/200705.mbox/[EMAIL PROTECTED]
).
The problem is that cached objects that gets hammered with
Cache-Control: max
Niklas Edmundsson wrote:
The solution is to NOT rewrite the on-disk headers when the following
conditions are true:
- The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating)
- The on-disk header hasn't expired.
- The request has max-age=0
This is perfectly OK with RFC2616 10.3.5 and
. Is there any configuration directive or client request that
could make mod_cache use headers from the cache when max-age=0? I
don't think so.
I suspect there is a more robust way of solving this:
In order to determine whether the entity was cached in the first place,
the cache would have had
On sön, 2007-07-29 at 20:34 +0200, Graham Leggett wrote:
Niklas Edmundsson wrote:
The solution is to NOT rewrite the on-disk headers when the following
conditions are true:
- The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating)
- The on-disk header hasn't expired.
- The
Joshua Slive wrote:
What needs to be validated is if, in fact, the headers with NEVER be
used. Is there any configuration directive or client request that
could make mod_cache use headers from the cache when max-age=0? I
don't think so.
The headers will be used by the next request - not just
On Jul 29, 2007, at 1:03 AM, Niklas Edmundsson wrote:
Attached is a patch for mod_cache (patch is for httpd-2.2.4) that
implements what I suggested in May (see the entire thread at
http://mail-archives.apache.org/mod_mbox/httpd-dev/200705.mbox/%
[EMAIL PROTECTED] ).
The problem
Hi!
Attached is a version of mod_limitipconn.c that works in conjunction
with mod_cache and httpd-2.2. We've been using this on ftp.acc.umu.se
for some time now without any unwanted issues.
The main problem with mod_limitipconn-0.22 was that since mod_cache
runs as a quick handler
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 request has max
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 by the
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---
My
101 - 200 of 732 matches
Mail list logo
