Re: Stealing Context Filter Error

Leo Cambilargiu [EMAIL PROTECTED] writes: When performing an internal_redirect after processing some POST data I an error 500 and the following two lines in my error_log: [Sun Aug 07 23:46:26 2005] [debug] mod_apreq2.c(510): [client 192.168.0.153] stealing filter context, referer:

Re: Stealing Context Filter Error

Joe Schaefer [EMAIL PROTECTED] writes: Leo Cambilargiu [EMAIL PROTECTED] writes: When performing an internal_redirect after processing some POST data I an error 500 and the following two lines in my error_log: [Sun Aug 07 23:46:26 2005] [debug] mod_apreq2.c(510): [client 192.168.0.153]

[PATCH] fix incorrect 304's responses when cache is unwritable

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 mod_cache should handle the

Adding OID group support to mod_ssl

Martin, David, See below a patch which now works with multiple group membership. That is IMHO as far as apache should go - anything beyond this should really be done through OpenSSL and some ASN1 'format' string passed along. Once you start looping through more complex sets one finds that

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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

Re: svn commit: r230592 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_http.c

At 03:34 AM 8/7/2005, [EMAIL PROTECTED] wrote: Sorry for being confused, but I just want to understand the commit policy/process on 2.0.x better. See http://httpd.apache.org/dev/voting.html for the definitive answer, and my post to Jeff Trawick shortly. And don't do what I did, which was try

Re: svn commit: r230592 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_http.c

At 08:39 PM 8/6/2005, Jeff Trawick wrote: On 8/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Aug 6 14:29:05 2005 New Revision: 230592 URL: http://svn.apache.org/viewcvs?rev=230592view=rev Log: As much as it pains me, seriously, it seems that reviewing the

Bug report for Apache httpd-1.3 [2005/08/07]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Bug report for Apache httpd-2.0 [2005/08/07]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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.

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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.

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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

Re: [PATCH] fix incorrect 304's responses when cache is unwritable

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

[PATCH] add remove empty directories option to htcacheclean

On Mon, Aug 08, 2005 at 12:04:44AM +0100, Colm MacCarthaigh wrote: Well that's a pretty each race to solve within httpd. It won't be able to create the headers, or the body. The patch I've submitted cleans up that slight race. The file won't be cached on that serve, but I don't think that's a

Re: svn commit: r230592 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_http.c

At 01:15 PM 8/7/2005, Joe Orton wrote: On Sat, Aug 06, 2005 at 06:54:45PM -0500, William Rowe wrote: Why do you bring this up now when I mentioned that I had vetoed the change a good three weeks ago, in STATUS, and advised on list that it would be reverted? Because you putting random crap

Re: [patch 1.3] The http_protocol.c C-L + T-E patch

Still looking for a vote on this fix to core for 1.3, preventing modules from seeing an invalid C-L + T-E combination from the client per RFC 2616. This does not apply to proxy (as implemented now) but may affect other handlers as I noted below. The sanest action seems to be; adopt our 2.0 core

Re: httpd-1.3 patchlets

That's wrowe, Mads and... Thanks, S. On Jul 20, 2005, at 8:40 AM, William A. Rowe, Jr. wrote: +1 on both patches; I can see how libhttpd.so gets stripped today. I'd commit if there were a couple more +1's. Bill At 08:16 AM 7/20/2005, Sander Temme wrote: Two very small patches against