On Friday 30 May 2008, Paul Querna wrote:
https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has
been in Debian testing and unstable for about 6 months without
problems. It is not an elegant solution but it works. Considering
that is is not clear how an elegant solution would look
On Fri, May 30, 2008 at 8:03 AM, Stefan Fritsch [EMAIL PROTECTED] wrote:
On Friday 30 May 2008, Paul Querna wrote:
https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has
been in Debian testing and unstable for about 6 months without
problems. It is not an elegant solution but it
Stefan Fritsch wrote:
Bugs as grave as this one are not acceptable in Debian packages for
extended periods of time.
Then change your default webserver to lighttpd.
I'm sure its bug free.
HTH.
-Paul
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 the
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:
|
On Fri, 30 May 2008 08:29:32 +0200
Sander Striker [EMAIL PROTECTED] wrote:
Bugs as grave as this one are not acceptable in Debian packages for
extended periods of time. The bug report has been open for over 1
year, I have attached my patch on 2007-11-16. It is marked as
critical since
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
Nick Kew wrote:
As for maintaining local patches, he's not the only one doing that,
and our license clearly allows it. Licenses that restrict such
things seem to be widely disliked: c.f. DJB/qmail.
We've made a concerted effort to supply all patches back, yet we always
find that we maintain
Nope.
My test client is a Perl SOCKET level IO deal and I am able
to send EXACTLY what was in your email as the 'fake' Treo
request, including the 'messed up' Host:redowadev.esri.com
header which is missing the SPACE character after the colon.
Doesn't make any difference here.
Apache
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 Thu, May 29, 2008 at 03:34:21PM -0700, Paul Querna wrote:
Stefan Fritsch wrote:
https://issues.apache.org/bugzilla/attachment.cgi?id=21137 has been in
Debian testing and unstable for about 6 months without problems. It is not
an elegant solution but it works. Considering that is is not
On Friday 30 May 2008, Nick Kew wrote:
I don't think I share your implied view about how grave this is.
I guess this is the main (or only?) problem with this patch/bug. I got
quite a few people complaining about it and therefore I wanted to fix
it.
I respect your opinion, but when
Stefan Fritsch wrote:
My mail in January already mentioned that the patch is in Debian, but
I guess now after the openssl debacle people are more sensitive. If
you think it would help, I could go through our patches and post a
list of the non-Debian specific ones here.
I think that would be
Ray...
Can you send me just the part of your httpd config that governs this
transaction and the redirect to the IIS server? I really would like to
reproduce this here. The moment I can actually make it happen I have
tools in place that will show exactly WHEN/WHERE it's happening (not
gdb. I
Ray...
Can you send me just the part of your httpd config that governs this
transaction and the redirect to the IIS server? I really would like to
reproduce this here. The moment I can actually make it happen I have
tools in place that will show exactly WHEN/WHERE it's happening (not
gdb. I
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
On 05/30/2008 08:17 PM, Stefan Fritsch wrote:
054_filename_in_warning.dpatch
Make a warning more useful, PR 39992 already in trunk:
http://svn.apache.org/viewvc?view=revrevision=420307
Trivial, this could still go into 2.2.9
Proposed for backport to 2.2.x as r661883
On 05/30/2008 01:49 PM, [EMAIL PROTECTED] wrote:
Author: jorton
Date: Fri May 30 04:49:31 2008
New Revision: 661666
URL: http://svn.apache.org/viewvc?rev=661666view=rev
Log:
Prevent CSRF attacks against the balancer-manager (CVE-2007-6420)
* modules/proxy/mod_proxy_balancer.c
25 matches
Mail list logo
