Re: PR42829
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 like, including this patch might make sense. Please don't put these kind of patches into the debian apache packages, especially ones that don't exist in trunk. (Things that are committed to turnk, and just are awaiting backport, I'm less concerned about, but this patch is a behavior change at the core of the MPMs.) 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 2008-01-16. If you don't want such patches in the Debian package, you need to fix such bugs faster (and comment on patches in bugzilla faster). Of course I understand that this is difficult because there are never enough people to fix bugs (we have the same problem). I admit that I should have followed up on the discussion in February, but I was quite busy and then forgot about it. Cheers, Stefan
Re: PR42829
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 works. Considering that is is not clear how an elegant solution would look like, including this patch might make sense. Please don't put these kind of patches into the debian apache packages, especially ones that don't exist in trunk. (Things that are committed to turnk, and just are awaiting backport, I'm less concerned about, but this patch is a behavior change at the core of the MPMs.) 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 2008-01-16. If you don't want such patches in the Debian package, you need to fix such bugs faster (and comment on patches in bugzilla faster). Of course I understand that this is difficult because there are never enough people to fix bugs (we have the same problem). To take it to the extreme, a fork being called 'Apache' isn't acceptable either. Please work with us here, even though it's a very low barrier for you to put patches in your package, much lower than to get it applied upstream (here). I admit that I should have followed up on the discussion in February, but I was quite busy and then forgot about it. Cheers, Sander
Re: PR42829
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
Adding purge/invalidation to mod_cache
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 same approach here - in a very basic patch. The patch actually works, you can call; PURGE /foo HTTP/1.1 Host: example.org Accept: foo/bar and it will actually go and remove the item from whatever cache its in, with the entity being negotiated as per the Accept headers. But before I move on to tidying it up to return better codes, work behind ACLs/auth, handle the uncached case better and add a PurgeEnable directive (or similar) - is this style of invalidation something suitable for httpd at all? or would people prefer to see something more like mod_proxy_balancer's full-scale html interface for doing this kind of thing at run-time? -- Colm purge.patch Description: Binary data
Re: Adding purge/invalidation to mod_cache
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: 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 up to things like spread. Esp. if that 'bus' can also contain pro-active warnings of one cache to the others that it has spotted something going out of date or whatever. However the current cache_remove_url_filter() backing is not quite ideal - with respect to purging 'recursively' into the Vary-ants. But I guess that is a problem which can be solved totally separately. Dw
Re: Adding purge/invalidation to mod_cache
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 up to things like spread. Esp. if that 'bus' can also contain pro-active warnings of one cache to the others that it has spotted something going out of date or whatever. However the current cache_remove_url_filter() backing is not quite ideal - with respect to purging 'recursively' into the Vary-ants. But I guess that is a problem which can be solved totally separately. 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. -- Colm
Re: Adding purge/invalidation to mod_cache
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 simple. The way Squid handles this is by implementing a non-standard PURGE HTTP method, so I've taken the same approach here - in a very basic patch. The patch actually works, you can call; PURGE /foo HTTP/1.1 Host: example.org Accept: foo/bar and it will actually go and remove the item from whatever cache its in, with the entity being negotiated as per the Accept headers. But before I move on to tidying it up to return better codes, work behind ACLs/auth, handle the uncached case better and add a PurgeEnable directive (or similar) - is this style of invalidation something suitable for httpd at all? or would people prefer to see something more like mod_proxy_balancer's full-scale html interface for doing this kind of thing at run-time? I don't think that we need a html interface. So the approach looks ok for me. Things that need fixing as you already said is to ensure that this runs behind ACLs/auth and as a comment I would not call the cache_remove_url_filter It would be also nice if the purge could be enabled only in a virtual host different from the one that does the caching (e.g. 127.0.0.1:8080), but I guess this adds some additional difficulties as the hostname of the virtual host doing the caching is contained in the key. So special care would need to be taken with 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 Regards Rüdiger
Re: Adding purge/invalidation to mod_cache
[..] | 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 | 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 the advantage is that standard http clients like wget can be used to purge a number of URLs (or based on wild cards) and it does not use any non-rfc methods. rahul
Re: Adding purge/invalidation to mod_cache
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 Henrik signature.asc Description: This is a digitally signed message part
Re: Adding purge/invalidation to mod_cache
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
Re: Adding purge/invalidation to mod_cache
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 not do this ? Or is location too path centric ? With the current approach Colm is using in its patch this would not work as we are only using the quick handler. We never evaluate the Limit or Location configuration. We act before this is done. Regards Rüdiger
Re: Adding purge/invalidation to mod_cache
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: | | 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 the advantage is that standard http clients like wget can be used to purge a number of URLs (or based on wild cards) and it does not use any non-rfc methods. If implemented as a handler it would also give you ACL/auth for free. OTOH it gets more difficult to implement the actual deleting from the cache. Furthermore you cannot delete specific variants. Regards Rüdiger
Re: PR42829
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 2008-01-16. If you don't want such patches in the Debian package, you need to fix such bugs faster (and comment on patches in bugzilla faster). Of course I understand that this is difficult because there are never enough people to fix bugs (we have the same problem). I don't think I share your implied view about how grave this is. I respect your opinion, but when maintaining your own patches, please consider also the problems discussed in my article at http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_vacuum/ (which goes to the heart of why Debian may get a pretty hostile reception amongst some Apache folks). To take it to the extreme, a fork being called 'Apache' isn't acceptable either. Please work with us here, even though it's a very low barrier for you to put patches in your package, much lower than to get it applied upstream (here). To be fair, I think Stefan _is_ working with us: he's put his patch in bugzilla, and (now, though not originally) he's raised it on the list. 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. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Adding purge/invalidation to mod_cache
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 (think curl_get_info) so that other modules can get info about cache objects (filenames, uri, sizes, etc.) -Our default cache store registers this post-store hook. It just writes the data out to a pipe - uri filename size expires\n -This piped program streams this info into a database (MySQL usually, as we had issues with SQLite) -Our cache manager is really just a fastcgi that uses the database to expire and purge cache objects. In a vary situation, we will get 3 post-store's for the initial cache: -first is the main key for main meta file -second is the varied key for the real meta file (the one that has headers, etc.) -third is the varied key/file for the data So a simple sql query for select file from my_table where url='/my/url' will return all 3. (LIKE and regex's work as well.) We also can easily keep track of cache size (select sum(object_size) from my_table), oldest entries, etc. Subsequent requests for same uri with different vary will add 2 entries to the database - varied meta and data. The fastcgi and pipe are because we prototyped all of this in perl and never rewrote it because it all works fairly well. Also, we had a few issues with mysql client directly in Apache and the pipe was just easier... -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: PR42829
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 a few local patches. We don't want to, but there are various bits that we just never successfully pushed back for one reason or another, e.g.: * mod_authn_alias.dep/.dsp/.mak: changes for building on Windows o Not sure why [as I'm no longer doing these builds myself] could be to allow us to build with an older MS studio * mod_deflate.c: added support for a response header which will allow responses (e.g. from Tomcat) to dynamically opt out of compression o code was suggested on the Apache lists, but uninteresting to Apache trunk apparently * util_ldap*.c: still changing '#if APR_HAS_SHARED_MEMORY' to '#if 0' as last we checked the shared memory stuff was still unstable with the worker MPM -- at least on Solaris and AIX -- Jess Holle
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
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 parses the 'Host:' header with no problems and, as you said, corrects the header when it forwards it upstream, but the original 'fixing' of the inbound header appears to have nothing to do with any decision making with regards to 'Connection: close'. It's still a total mystery where that 'Connection: close' is actually coming from and I still cannot make it happen. Ah, interesting. So much for that theory... Glad you have a working solution but something tells me this isn't over yet. Still curious about who/what is/was adding that 'Connection: close' and why. If it starts appearing again give a shout. Well, this is definitely still something I can reproduce easily (just have to remove the RequestHeader directive), and I have a test server where it's easy to troubleshoot. I would *love* to step through this with gdb -- anyone out there a gdb expert enough to tell me how to capture a bit of runtime and play it back later so I can step through the source after the fact? Doing it in real time seems to not give consistent results. Maybe oprofile would do the trick for me... seems like there should be a way for gdb to capture the session though if its attached... I'll dig into that sometime unless someone can give me a pointer off the top of their head :) Thanks, Ray
Re: Adding purge/invalidation to mod_cache
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 source, but
it's *very* stale). If I find the time next week, I'll get this
working again, I think it might be useful to others!
--
Colm
/* Copyright 2001-2005 The Apache Software Foundation or its licensors, as
* applicable.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/*
* htcacheadmin.c: a utility to allow administrators to track down urls
* in their caches, and perform actions on that basis.
*
* Contributed by Colm MacCarthaigh colm stdlib.net
* 11 Aug 2005
*/
#include apr.h
#include apr_lib.h
#include apr_strings.h
#include apr_file_io.h
#include apr_file_info.h
#include apr_pools.h
#include apr_md5.h
#include apr_getopt.h
#include apr_date.h
#include apr_uri.h
#if APR_HAVE_UNISTD_H
#include unistd.h
#endif
#if APR_HAVE_STDLIB_H
#include stdlib.h
#endif
/* mod_disk_cache.c extract start */
#define VARY_FORMAT_VERSION 3
#define DISK_FORMAT_VERSION 4
typedef struct
{
/* Indicates the format of the header struct stored on-disk. */
apr_uint32_t format;
/* The HTTP status code returned for this response. */
int status;
/* The size of the entity name that follows. */
apr_size_t name_len;
/* The number of times we've cached this entity. */
apr_size_t entity_version;
/* Miscellaneous time values. */
apr_time_t date;
apr_time_t expire;
apr_time_t request_time;
apr_time_t response_time;
} disk_cache_info_t;
/* mod_disk_cache.c extract end */
/* cache_util.c extract started */
static void cache_hash(const char *it, char *val, int ndepth, int nlength)
{
apr_md5_ctx_t context;
unsigned char digest[16];
char tmp[22];
int i, k, d;
unsigned int x;
static const char enc_table[64] =
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_@;
apr_md5_init(context);
apr_md5_update(context, (const unsigned char *) it, strlen(it));
apr_md5_final(digest, context);
/* encode 128 bits as 22 characters, using a modified uuencoding
* the encoding is 3 bytes - 4 characters* i.e. 128 bits is
* 5 x 3 bytes + 1 byte - 5 * 4 characters + 2 characters
*/
for (i = 0, k = 0; i 15; i += 3) {
x = (digest[i] 16) | (digest[i + 1] 8) | digest[i + 2];
tmp[k++] = enc_table[x 18];
tmp[k++] = enc_table[(x 12) 0x3f];
tmp[k++] = enc_table[(x 6) 0x3f];
tmp[k++] = enc_table[x 0x3f];
}
/* one byte left */
x = digest[15];
tmp[k++] = enc_table[x 2]; /* use up 6 bits */
tmp[k++] = enc_table[(x 4) 0x3f];
/* now split into directory levels */
for (i = k = d = 0; d ndepth; ++d) {
memcpy(val[i], tmp[k], nlength);
k += nlength;
val[i + nlength] = '/';
i += nlength + 1;
}
memcpy(val[i], tmp[k], 22 - k);
val[i + 22 - k] = '\0';
}
/* cache_util.c extract end */
static apr_file_t *errfile; /* stderr file handle */
/* short program name as called */
static const char *shortname = htcacheadmin;
/*
* usage info
*/
#define NL APR_EOL_STR
static void usage(void)
{
apr_file_printf(errfile,
%s -- utility for administration of the disk cache.NL
Usage: %s [-gq] [-h HOSTNAME] -c ROOT -d DIRLEVEL -l DIRLENGTH URL NL
%s [-emHRbD] [-E DATE] HEADERFILE NL
NL
Options: NL
NL
Locate mode: NL
NL
-c Use ROOT as the root directory for the cache. Must be identical NL
to the CacheRoot setting for Apache.NL
NL
-d Use DIRLEVEL as the number of subdirectories mod_disk_cache NL
creates for cached files. Must be identical to the NL
CacheDirLevels setting for Apache. NL
Re: PR42829
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 clear how an elegant solution would look like, including this patch might make sense. Please don't put these kind of patches into the debian apache packages, especially ones that don't exist in trunk. Why not, is this some kind of distros-can't-be-trusted-to-run-patch reaction after the Debian OpenSSL PRNG incident? Blah. 1) we-the-committers failed to do anything useful about this bug 2) Stefan has a patch 3) having more test data from people running that patch is useful If you don't want people *patching* the *Apache source code* (god forbid!), then we need to go pick another license. joe
Re: PR42829
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 maintaining your own patches, please consider also the problems discussed in my article at http://www.regdeveloper.co.uk/2006/11/04/apache_packages_support_va cuum/ (which goes to the heart of why Debian may get a pretty hostile reception amongst some Apache folks). Yes, this is definitely a problem, but not easy to fix. I hope I will find some time soon to try to improve the situation. In any case the problem is less about patches but more about the configuration and the additional scripts we ship with apache. For example the configuration is split into many small files because this makes upgrades easier because of the way dpkg handles config files. To take it to the extreme, a fork being called 'Apache' isn't acceptable either. Please work with us here, even though it's a very low barrier for you to put patches in your package, much lower than to get it applied upstream (here). Fixing bugs is not forking. We don't include many patches that are not either bug fixes or related to build or file system layout issues. For example we don't add features or change the behaviour (unless the component comes in a separate package that is clearly marked as non-standard, like the mpm-itk). And for the bug fixes, these are usually from branches/2.2.x or from the Apache bugzilla. To be fair, I think Stefan _is_ working with us: he's put his patch in bugzilla, and (now, though not originally) he's raised it on the list. I raised the issue in January (http://marc.info/?l=apache-httpd-devm=119945416529706w=2) and there was some discussion with Joe Orton, but no conclusion about what would be the proper fix. But since I had a fix that worked for me, I didn't see any reason to revert the patch. 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. Cheers, Stefan
Re: PR42829
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 helpful and a good thing, Thanks, -Paul
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
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 don't use it). All I have here is a simple mod_proxy setup with a single ProxyPass staement redirecting all requests to a back end. You are doing something with Virtual Hosts here, right? That COULD be making a difference. Yours Kevin Kiley -Original Message- From: Ray Van Dolson [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Fri, 30 May 2008 08:08:55 -0700 Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy 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 parses the 'Host:' header with no problems and, as you said, corrects the header when it forwards it upstream, but the original 'fixing' of the inbound header appears to have nothing to do with any decision making with regards to 'Connection: close'. It's still a total mystery where that 'Connection: close' is actually coming from and I still cannot make it happen. Ah, interesting. So much for that theory... Glad you have a working solution but something tells me this isn't over yet. Still curious about who/what is/was adding that 'Connection: close' and why. If it starts appearing again give a shout. Well, this is definitely still something I can reproduce easily (just have to remove the RequestHeader directive), and I have a test server where it's easy to troubleshoot. I would *love* to step through this with gdb -- anyone out there a gdb expert enough to tell me how to capture a bit of runtime and play it back later so I can step through the source after the fact? Doing it in real time seems to not give consistent results. Maybe oprofile would do the trick for me... seems like there should be a way for gdb to capture the session though if its attached... I'll dig into that sometime unless someone can give me a pointer off the top of their head :) Thanks, Ray
Re: Palm Treo access to OWA via Apache 2.2.x Proxy
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 don't use it). All I have here is a simple mod_proxy setup with a single ProxyPass staement redirecting all requests to a back end. You are doing something with Virtual Hosts here, right? That COULD be making a difference. Yours Kevin Kiley -Original Message- From: Ray Van Dolson [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Fri, 30 May 2008 08:08:55 -0700 Subject: Re: Palm Treo access to OWA via Apache 2.2.x Proxy 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 parses the 'Host:' header with no problems and, as you said, corrects the header when it forwards it upstream, but the original 'fixing' of the inbound header appears to have nothing to do with any decision making with regards to 'Connection: close'. It's still a total mystery where that 'Connection: close' is actually coming from and I still cannot make it happen. Ah, interesting. So much for that theory... Glad you have a working solution but something tells me this isn't over yet. Still curious about who/what is/was adding that 'Connection: close' and why. If it starts appearing again give a shout. Well, this is definitely still something I can reproduce easily (just have to remove the RequestHeader directive), and I have a test server where it's easy to troubleshoot. I would *love* to step through this with gdb -- anyone out there a gdb expert enough to tell me how to capture a bit of runtime and play it back later so I can step through the source after the fact? Doing it in real time seems to not give consistent results. Maybe oprofile would do the trick for me... seems like there should be a way for gdb to capture the session though if its attached... I'll dig into that sometime unless someone can give me a pointer off the top of their head :) Thanks, Ray
Re: Adding purge/invalidation to mod_cache
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 /used/ to handle this situation. (I've attached the source, but it's *very* stale). If I find the time next week, I'll get this working again, I think it might be useful to others! Nice. Looking forward to the result if you find some time. Regards Rüdiger
Re: List of Debian patches, part 1
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 055_htpasswd_salt_generation.dpatch PR 31440 already in trunk: http://svn.apache.org/viewvc?view=revrevision=629159 http://svn.apache.org/viewvc?view=revrevision=629164 Proposed for backport to 2.2.x as r661890. Regards Rüdiger
Re: svn commit: r661666 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_balancer.c
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 (balancer_init): New function.
(balancer_handler): Place a nonce in the form output, and check that
the submitted form data includes that nonce.
(ap_proxy_balancer_register_hook): Register the new post_config hook.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c?rev=661666r1=661665r2=661666view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c Fri May 30 04:49:31
2008
@@ -21,9 +21,12 @@
#include ap_mpm.h
#include apr_version.h
#include apr_hooks.h
+#include apr_uuid.h
module AP_MODULE_DECLARE_DATA proxy_balancer_module;
+static apr_uuid_t balancer_nonce;
+
static int proxy_balancer_canon(request_rec *r, char *url)
{
char *host, *path;
@@ -619,6 +622,27 @@
}
}
+/* post_config hook: */
+static int balancer_init(apr_pool_t *p, apr_pool_t *plog,
+ apr_pool_t *ptemp, server_rec *s)
+{
+void *data;
+const char *userdata_key = mod_proxy_balancer_init;
+
+/* balancer_init() will be called twice during startup. So, only
+ * set up the static data the second time through. */
+apr_pool_userdata_get(data, userdata_key, s-process-pool);
+if (!data) {
+apr_pool_userdata_set((const void *)1, userdata_key,
+ apr_pool_cleanup_null, s-process-pool);
+return OK;
+}
+
+apr_uuid_get(balancer_nonce);
Why don't we do apr_uuid_format already here and store the string directly?
Regards
Rüdiger
