Justin Erenkrantz wrote:
--On August 11, 2005 10:21:37 AM +0100 Colm MacCarthaigh
[EMAIL PROTECTED] wrote:
On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches,
On Fri, Aug 12, 2005 at 05:38:40AM +0200, Plm, Rdiger, VIS wrote:
In the case that you are caching a response from a backend app server or
a cgi script I can imagine situations where one variant is 404 and another
one is not. Dw also pointed that out.
From my personal point of view we should
On Thu, Aug 11, 2005 at 11:48:21PM -0700, Justin Erenkrantz wrote:
Right. I think Paul mentioned that we also need to fix up htcacheclean to
remove the .vary subdirectories as well. -- justin
Next time someone is commiting to htcacheclean; it's define's for
VARY_FORMAT_VERSION and
Justin Erenkrantz wrote:
On Fri, Aug 12, 2005 at 05:38:40AM +0200, Plm, Rdiger, VIS wrote:
In the case that you are caching a response from a backend app server or
a cgi script I can imagine situations where one variant is 404 and another
one is not. Dw also pointed that out.
From my personal
--On August 8, 2005 9:46:52 PM +0200 [EMAIL PROTECTED] wrote:
log_correction.diff:
...
dir_removal_patch.diff:
Committed in r232335 and r232334, respectively.
Thanks! -- justin
On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
Would you mind writing up a
--On August 11, 2005 10:21:37 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few
In a message dated 8/11/2005 12:42:35 PM Central Daylight Time, [EMAIL PROTECTED] writes:
The code will remove the header file and the disk file; but it also likely needs to go up a 'level' and remove all variants. Because if we get a 404 on a varied entity, it also means that all variants
On Thu, 11 Aug 2005 [EMAIL PROTECTED] wrote:
It is possible ( and legal? ) for a COS ( Content Origin Server ) to return
a '404' on one variant of an entity but not on another.
Regardless - it is quite a common thing to do.
Dw.
[..cut..]
Thanks! I've committed this in r231486, r231487, and r231488. I re-split
them up to make it easier for people to review the commits.
However, there remains an issue in mod_disk_cache's remove_url: I don't think
it properly handles removing the Vary condition files. I went ahead
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
Would you mind writing up a log message for this patch?
I've lost track of what it's supposed to
--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
Would you mind writing up a log message for this patch?
I've lost track of what it's supposed to
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 12:45:21AM +0200, [EMAIL PROTECTED] wrote:
Is a traversal really needed? What about going back the full path of the
header / data file to the cache root and removing each component on the
way by calling apr_dir_remove on each component until it
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
Is a traversal really needed? What about going back the full path of the
header / data file to the cache root and removing each component on the
way by calling apr_dir_remove on each component until it fails?
I'm not sure
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
[..cut..]
The patch is attached, and I've been testing it for the last few hours
without problem. The code is now running on ftp.heanet.ie. (along
with htcacheclean -t).
Looks very good to me.
Andreas Steinmetz said:
The problem is that you can't remove directories with htcacheclean
without generating race conditions wrt. httpd.
In this case the race in httpd should be fixed.
In theory, httpd should attempt to create the directory, then attempt to
move the file to that directory.
Colm MacCarthaigh wrote:
On Mon, Aug 08, 2005 at 10:33:47AM +0200, [EMAIL PROTECTED] wrote:
[..cut..]
O.k., I've merged our two patches, but I've changed a few things, tell
me if there's anothing you think is wrong;
I attached two further patches to your merged patch:
Graham Leggett wrote:
Andreas Steinmetz said:
The problem is that you can't remove directories with htcacheclean
without generating race conditions wrt. httpd.
In this case the race in httpd should be fixed.
In theory, httpd should attempt to create the directory, then attempt to
Colm MacCarthaigh wrote:
I finally developed some time to look into this. mod_cache doesn't
behave very nicely when the cache area fills. Of course administators
should make sure it doesn't fill in the first place, but nevertheless a
few people have hit this bug (me included) and I think
On Sun, Aug 07, 2005 at 09:59:15PM +0200, [EMAIL PROTECTED] wrote:
As you already mentioned the remove_url implementation
of mod_disk_cache is currently an empty dummy :-).
I've been thinking about that, but it's not entirely as easy as it first
seems, or indeed as htcacheclean wrongly assumes.
Colm MacCarthaigh wrote:
For what it's worth though, htcacheclean itself has this massive bug,
and does not do any directory cleanup, so your patch isn't alone in
doing this.
The problem is that you can't remove directories with htcacheclean
without generating race conditions wrt. httpd.
Colm MacCarthaigh wrote:
On Sun, Aug 07, 2005 at 09:59:15PM +0200, [EMAIL PROTECTED] wrote:
As you already mentioned the remove_url implementation
of mod_disk_cache is currently an empty dummy :-).
I've been thinking about that, but it's not entirely as easy as it first
seems, or indeed
On Mon, Aug 08, 2005 at 12:07:09AM +0200, Andreas Steinmetz wrote:
Colm MacCarthaigh wrote:
For what it's worth though, htcacheclean itself has this massive bug,
and does not do any directory cleanup, so your patch isn't alone in
doing this.
The problem is that you can't remove
On Mon, Aug 08, 2005 at 12:45:21AM +0200, [EMAIL PROTECTED] wrote:
Is a traversal really needed? What about going back the full path of the
header / data file to the cache root and removing each component on the
way by calling apr_dir_remove on each component until it fails?
I'm not sure if
24 matches
Mail list logo
