Re: Ip address parser bug?
Hi, On Wed, Jan 25, 2012 at 7:05 PM, Mathijs wrote: > Using comments on the same line as configuration directives is not allowed > (although it will probably work in some cases), see the second paragraph > on http://httpd.apache.org/docs/trunk/configuring.html#syntax Thanks. Than it's no bug at all. I guess I should have read the manual first ;-) Regards, Bart > > Kind Regards, > Mathijs - Sling @ irc://irc.freenode.net/httpd > > On Wed, Jan 25, 2012 at 6:58 PM, Bart van der Schans > wrote: >> >> Hi all, >> >> Recently I ran into a strange ip parsing bug in a Allow from or Deny >> from statement. When you have a colon in comment after the from >> statement like this: >> >> Allow from 66.6.6.6 # test : in comment >> >> You get an error with: "The specified IP address is invalid." >> >> Is this a known issue? >> >> If you want to reproduce it in the test suite, just add "# test : in >> comment" in t/modules/access.t on line 27 (trunk r1235848). >> >> Regards, >> Bart > > > > > -- > Gr, > > Mathijs -- Amsterdam - Oosteinde 11, 1017 WT Amsterdam Boston - 1 Broadway, Cambridge, MA 02142 US +1 877 414 4776 (toll free) Europe +31(0)20 522 4466 www.onehippo.com
Ip address parser bug?
Hi all, Recently I ran into a strange ip parsing bug in a Allow from or Deny from statement. When you have a colon in comment after the from statement like this: Allow from 66.6.6.6 # test : in comment You get an error with: "The specified IP address is invalid." Is this a known issue? If you want to reproduce it in the test suite, just add "# test : in comment" in t/modules/access.t on line 27 (trunk r1235848). Regards, Bart
Add Set-Cookie to default cache ignore headers?
Hi all, Is there any valid reason to allow mod_cache to cache Set-Cookieheaders? Recently we encountered some problems because of thisbehavior [1]. Of course you can always configure mod_cache to notcache header, but to me it would make sense to add it to the list ofdefault ignored headers [2]. The attached patch is rather trivial.. Regards, Bart [1] http://confluence.atlassian.com/display/CONFKB/Request+Assumes+Identity+of+Another+User+who+Logs+in+Concurrently+Due+to+Apache+CacheIgnoreHeaders[2] http://httpd.apache.org/docs/2.2/mod/mod_cache.html#cacheignoreheaders
Add Set-Cookie to default cache ignore headers?
Hi all, Is there any valid reason to allow mod_cache to cache Set-Cookie headers? Recently we encountered some problems because of this behavior [1]. Of course you can always configure mod_cache to not cache header, but to me it would make sense to add it to the list of default ignored headers [2]. The attached patch is rather trivial.. Regards, Bart [1] http://confluence.atlassian.com/display/CONFKB/Request+Assumes+Identity+of+Another+User+who+Logs+in+Concurrently+Due+to+Apache+CacheIgnoreHeaders [2] http://httpd.apache.org/docs/2.2/mod/mod_cache.html#cacheignoreheaders Index: modules/cache/cache_util.c === --- modules/cache/cache_util.c (revision 1195435) +++ modules/cache/cache_util.c (working copy) @@ -979,7 +979,7 @@ /* Make a copy of the headers, and remove from * the copy any hop-by-hop headers, as defined in Section - * 13.5.1 of RFC 2616 + * 13.5.1 of RFC 2616 and remove the Set-Cookie header. */ headers_out = apr_table_copy(pool, t); @@ -991,6 +991,7 @@ apr_table_unset(headers_out, "Trailers"); apr_table_unset(headers_out, "Transfer-Encoding"); apr_table_unset(headers_out, "Upgrade"); +apr_table_unset(headers_out, "Set-Cookie"); conf = (cache_server_conf *)ap_get_module_config(s->module_config, &cache_module);
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
On Wed, Dec 9, 2009 at 9:01 PM, Michael Felt wrote: > I confess to being a bit lost in all of this. I am still stuck with the pcre > issue, even after adding: > --with-pcre=/data/prj/pcre-8.00 \ > > checking for pcre-config... false > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00 > > mich...@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00 > mich...@x054:[/data/prj/pcre-8.00]find . -name pcre-config > ./pcre-config > mich...@x054:[/data/prj/pcre-8.00] > > Suggestions? And I hope I am not just being blind... Doesn't configure check for -x "$with_pcre/bin/pcre-config"? Then you should have the pcre-config script in a bin sub folder. Bart
Re: Mod_cache expires check
Ruediger Pluem wrote:
Providing a better reference to the patch you are talking about would be a
start :-).
Of course, and now when I'm trying to find Davi's mail from the 18th of
January in the archive it seems to be missing, so maybe it didn't even
make it to the list :( So here is his patch again.
The original problem was described in:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200701.mbox/[EMAIL PROTECTED]
Regards,
Bart
Index: modules/cache/mod_cache.c
===
--- modules/cache/mod_cache.c (revision 497262)
+++ modules/cache/mod_cache.c (working copy)
@@ -372,13 +372,8 @@
exps = apr_table_get(r->headers_out, "Expires");
}
if (exps != NULL) {
-if (APR_DATE_BAD == (exp = apr_date_parse_http(exps))) {
-exps = NULL;
-}
+exp = apr_date_parse_http(exps);
}
-else {
-exp = APR_DATE_BAD;
-}
/* read the last-modified date; if the date is bad, then delete it */
lastmods = apr_table_get(r->err_headers_out, "Last-Modified");
@@ -424,21 +419,24 @@
*/
reason = apr_psprintf(p, "Response status %d", r->status);
}
+else if (r->args && exps == NULL) {
+/* if query string present but no expiration time, don't cache it
+ * (RFC 2616/13.9)
+ */
+reason = "Query string present but no expires header";
+}
+/* XXX: APR_DATE_BAD (0) is a valid date */
else if (exps != NULL && exp == APR_DATE_BAD) {
/* if a broken Expires header is present, don't cache it */
reason = apr_pstrcat(p, "Broken expires header: ", exps, NULL);
}
-else if (exp != APR_DATE_BAD && exp < r->request_time)
+else if (exps != NULL && exp < r->request_time)
{
-/* if a Expires header is in the past, don't cache it */
+/* if a Expires header is in the past, don't cache it.
+ * it may also be a broken header too, anyway.. we won't cache it
+ */
reason = "Expires header already expired, not cacheable";
}
-else if (r->args && exps == NULL) {
-/* if query string present but no expiration time, don't cache it
- * (RFC 2616/13.9)
- */
-reason = "Query string present but no expires header";
-}
else if (r->status == HTTP_NOT_MODIFIED &&
!cache->handle && !cache->stale_handle) {
/* if the server said 304 Not Modified but we have no cache
@@ -686,7 +684,7 @@
* else
* expire date = date + defaultexpire
*/
-if (exp == APR_DATE_BAD) {
+if (exps == NULL) {
char expire_hdr[APR_RFC822_DATE_LEN];
/* if lastmod == date then you get 0*conf->factor which results in
Re: Mod_cache expires check
Bart van der Schans wrote: Is there any change the patch from Davi will make it in the trunk (and That should have read chance of course, sorry about the typo. Bart
Re: Mod_cache expires check
Bart van der Schans wrote: Davi Arnaut wrote: > > Looking at it more, the previous check it's also useless. Attempted patch... I finally had some time to test the patch and it seems to work correctly. It still recognizes Unix epoch as a bad date, but mod_cache won't cache it. Is there any change the patch from Davi will make it in the trunk (and hopefully backported to the branch)? What is the correct way to move forward with this? Can I help in some way? Regards, Bart
Re: Mod_cache expires check
Davi Arnaut wrote: > > Looking at it more, the previous check it's also useless. Attempted patch... I finally had some time to test the patch and it seems to work correctly. It still recognizes Unix epoch as a bad date, but mod_cache won't cache it. Regards, Bart
Re: mod_cache+mod_rewrite behaviour
Akins, Brian wrote: In our home-grown cache module, the "rules" are actually provider based. We have providers that provide matches based on exact match, string match, regex, prefix, environment variable, and other assorted things. Something like: CacheEnable disk regex=\.gif$ ignore_query CacheEnable disk prefix=/somethingelse foo=bar Cacheenable mem exact=/strange/stuff.asp CacheDisable regex=\.php$ Default "match provider" could be prefix to allow users to still do: CacheEnable disk /cache_me That would be very useful in our setups (as reverse caching proxy). Although it would be nice if the "normal" options would set the default and the extra options or rules (maybe comma seperated?) would override them. Maybe something like: CacheIgnoreNoLastMod Off CacheEnable disk regex=\.gif$ IgnoreQuery=on,IgnoreNoLastMod=on Regards, Bart
Re: mod_cache+mod_rewrite behaviour
Fredrik Widlund wrote: > > I understand this has been discussed earlier in the " mod_cache, don't > always run as a quick handler." discussion, and I'd like to second this > request. And/or I'd be very happy to add a "CacheIgnoreQueryString On" > option to mod_cache. I also would like to have this option. It will break RFC 2616/13.9 if you turn it on though. If there's more support for this I could submit a patch for it... Regards, Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Mod_cache expires check
Roy T. Fielding wrote:
On Jan 17, 2007, at 12:23 PM, Ruediger Pluem wrote:
On 01/15/2007 01:56 PM, Bart van der Schans wrote:
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD && exp < r->request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = "Expires header already expired, not cacheable";
}
This check fails to correctly identify the expires header "Thu, 01 Jan
1970 00:00:00 GMT". The apr_date_parse_http function(exps) returns
(apr_time_t)0 which is equal to APR_DATE_BAD, but it should recognize it
as an already expired header. Is there a way to distinct between
APR_DATE_BAD and the unix epoch? Or is that considered a bad date?
I would say 0 is not a bad day. But if this is a bug it is an
APR(-util) bug.
Thus I forward it to the apr dev list.
No, it is a bug in the expression. A date is an unsigned value and any
error is specifically forced to 0 so that the comparison
if (exp < r->request_time)
will be true if exp == APR_DATE_BAD (as is desired in this case).
That expression would also return true if the expires header is not set,
which is probably not desired.
As I understand it, there are four cases:
a - Expires not set
b - Expires set to a bad (unparsable) date
c - Expires set to a date in the past (from and including 0)
d - Expires set to the future (up to +1 year)
According to rfc 2616 14.21, b and c should be treated as the same, but
mod_cache treats a and b as the same:
exps = apr_table_get(r->err_headers_out, "Expires");
if (exps == NULL) {
exps = apr_table_get(r->headers_out, "Expires");
}
if (exps != NULL) {
if (APR_DATE_BAD == (exp = apr_date_parse_http(exps))) {
exps = NULL;
}
}
else {
exp = APR_DATE_BAD;
}
If exp would be set to something like NOT_SET when the expires header is
not set (in the else block) the check later on could be:
else if (exp != NOT_SET && exp < r->request_time)
{
/* if a Expires header is in the past or bad, don't cache it */
reason = "Expires header already expired or bad, not cacheable";
}
It would seem obvious to set exp to NULL instead of NOT_SET, but NULL ==
APR_DATE_BAD evaluates to true (at least on my linux boxes) which would
make it hard to discern later on between case a. and b.
Regards,
Bart
Mod_cache expires check
In r463496 the following check was added to mod_cache.c :
else if (exp != APR_DATE_BAD && exp < r->request_time)
{
/* if a Expires header is in the past, don't cache it */
reason = "Expires header already expired, not cacheable";
}
This check fails to correctly identify the expires header "Thu, 01 Jan
1970 00:00:00 GMT". The apr_date_parse_http function(exps) returns
(apr_time_t)0 which is equal to APR_DATE_BAD, but it should recognize it
as an already expired header. Is there a way to distinct between
APR_DATE_BAD and the unix epoch? Or is that considered a bad date?
Regards,
Bart
Re: httpd 2.2 cache - disable and enable
Matthieu Estrade wrote: > Bart van der Schans a écrit : >> Matthieu Estrade wrote: >> > It could be great to do it by type, but it can have a big side effect. > Usually, resources not identified by extension are resources delivering > content based on dynamic information. > If these dynamic information are not in the query string, it's > definitively dead to do caching on this resource. > > ex: > > script.php?action=gimme_pdf will return a pdf content > Cookie: phpsessionid=JKHdheehKJHEDJKHhe > > script.php?action=display_my_account return html. > Cookie: phpsessionid=6537656356753 AFAIK you can set the mime type with the php script. Sending different content with the same URL makes it a lot harder to cache. > IMHO, a regexp based cache enable or disable could be very usefull for a > default caching policy shipped with httpd. > We could do per default caching only on all images, css and all static > content. It would be useful to be able to match caching on something like "/.+/images/.+" Bart
Re: httpd 2.2 cache - disable and enable
Matthieu Estrade wrote: > Colm MacCarthaigh a écrit : > I agree on this point, but people using this directive choose to loose > time on this regexp check. > The problem i have is many people wants to enable cache on .gif and > .jpeg and .pdf, but they don't know the exact path. Wouldn't it be easier to do a match on mime type, like ExpiresByType? Bart
Re: load balancer and http(s) sticky sessions
Paul Querna wrote: > Jim Jagielski wrote: >> There is a lot of confusion where the users think that >> simply adding the stickysession param to the http worker >> attribute *adds* the required sticky session info (cookie). >> >> I'm looking into adding functionality that actually >> does that and therefore avoiding this large and common >> misconception. > > I think we should support both methods. > > Yeah, in many cases, it would be easier if the LB could figure out the > stickysession for me. Also adding different sticky session methods like add parameters to the url would be useful. It's not always possible to set cookies. Also sticky session based on client ip would be nice. Although that would probably mean that the server must keep track of the sessions. Bart > > -Paul > >
Re: suexec for directories
Ben Charlton wrote:
> I'm currently involved in building a new webserver environment to
> replace a 6 year old server running a large website with a fairly broken
> publishing model.
>
> One of the things we'd like to do is lock down PHP so that we're no
> longer using mod_php running all as one user, and this means using
> cgi mode under suexec. The kicker is that we can't use a separate vhost
> for each department/publishing group for various political reasons.
>
> Naturally, the suexec documentation says "do not edit this on pain of
> death", etc, but we don't seem to have any choice if we want to support
> suexec configuration local to the stanza. I can understand
> why only virtualhosts were supported under 1.3, as suexec seems to be a
> massive hack that co-opts the User and Group directives, but mod_suexec
> under apache 2.2 seems much cleaner.
>
> What I would like to know is, a) is there a big obvious answer to this
> that I'm missing, and b) does the following diff for mod_suexec.c open
> up subtle and terrifying security holes that we've managed to overlook?
Did you have a look at mod_suphp? http://www.suphp.org/Home.html
Regards,
Bart
>
>
> 63c63
> < const char *err = ap_check_cmd_context(cmd,
> NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT);
> ---
>> const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT);
>
> 118c118
> < AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL, RSRC_CONF,
> ---
>
>> AP_INIT_TAKE2("SuexecUserGroup", set_suexec_ugid, NULL,
>> RSRC_CONF|ACCESS_CONF,
>
>
> Many thanks,
> Ben
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-
[EMAIL PROTECTED] / http://www.hippo.nl
--
mod_expires ExpiresOverride
Hi all,
I found that there is no option to override the Expires header with
mod_expires. Especially when you use apache (with mod_cache) as a
reverse proxy it can be very useful to be able to override the expires
headers. I've created a patch for mod_expires for the 2.2.x branch
(trunk is similar) which adds the option "ExpiresOverride On|Off".
Are there more people interested to have this in the 2.2.x branch or trunk?
Regards,
Bart
--- httpd-2.2.x-orig/modules/metadata/mod_expires.c 2006-07-13
16:18:03.0 +0200
+++ httpd-2.2.x/modules/metadata/mod_expires.c 2006-07-13 16:19:21.0
+0200
@@ -167,6 +167,7 @@
typedef struct {
int active;
+int override;
int wildcards;
char *expiresdefault;
apr_table_t *expiresbytype;
@@ -176,6 +177,9 @@
*/
#define DIR_CMD_PERMS OR_INDEXES
+#define OVERRIDE_ON 1
+#define OVERRIDE_OFF 0
+#define OVERRIDE_DONTCARE 2
#define ACTIVE_ON 1
#define ACTIVE_OFF 0
#define ACTIVE_DONTCARE 2
@@ -187,12 +191,28 @@
expires_dir_config *new =
(expires_dir_config *) apr_pcalloc(p, sizeof(expires_dir_config));
new->active = ACTIVE_DONTCARE;
+new->override = OVERRIDE_DONTCARE;
new->wildcards = 0;
new->expiresdefault = NULL;
new->expiresbytype = apr_table_make(p, 4);
return (void *) new;
}
+static const char *set_expiresoverride(cmd_parms *cmd, void *in_dir_config,
int arg)
+{
+expires_dir_config *dir_config = in_dir_config;
+
+/* if we're here at all it's because someone explicitly
+ * set the override flag
+ */
+
+dir_config->override = OVERRIDE_ON;
+if (arg == 0) {
+dir_config->override = OVERRIDE_OFF;
+}
+return NULL;
+}
+
static const char *set_expiresactive(cmd_parms *cmd, void *in_dir_config, int
arg)
{
expires_dir_config *dir_config = in_dir_config;
@@ -351,6 +371,8 @@
{
AP_INIT_FLAG("ExpiresActive", set_expiresactive, NULL, DIR_CMD_PERMS,
"Limited to 'on' or 'off'"),
+AP_INIT_FLAG("ExpiresOverride", set_expiresoverride, NULL, DIR_CMD_PERMS,
+ "Limited to 'on' or 'off'"),
AP_INIT_TAKE2("ExpiresByType", set_expiresbytype, NULL, DIR_CMD_PERMS,
"a MIME type followed by an expiry date code"),
AP_INIT_TAKE1("ExpiresDefault", set_expiresdefault, NULL, DIR_CMD_PERMS,
@@ -371,6 +393,13 @@
new->active = add->active;
}
+if (add->override == OVERRIDE_DONTCARE ) {
+ new->override = base->active;
+}
+else {
+new->override = add->override;
+}
+
if (add->expiresdefault != NULL) {
new->expiresdefault = add->expiresdefault;
}
@@ -427,7 +456,7 @@
}
expires = base + additional;
-apr_table_mergen(t, "Cache-Control",
+apr_table_setn(t, "Cache-Control",
apr_psprintf(r->pool, "max-age=%" APR_TIME_T_FMT,
apr_time_sec(expires - r->request_time)));
timestr = apr_palloc(r->pool, APR_RFC822_DATE_LEN);
@@ -466,7 +495,7 @@
expiry = apr_table_get(r->headers_out, "Expires");
t = r->headers_out;
}
-if (expiry == NULL) {
+if (expiry == NULL || (conf->override == OVERRIDE_ON)) {
/*
* No expiration has been set, so we can apply any managed by
* this module. First, check to see if there is an applicable
Re: Possible new cache architecture
Brian Akins wrote: > The components: > mod_http_cache: what mod_cache is currently One thing about the current implementation. Mod_cache does server side caching, but also set expires headers witch trigger client (browser) caching. Right now you can't turn off setting the expires header with mod_cache. I think it would be nice to have an option to configure this. WDYT? Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Nick Kew wrote: > On Monday 24 April 2006 11:24, Bart van der Schans wrote: >> Hi all, >> >> I'm quite new to the list, so I'm just wondering how it works. Jeff >> Tharp and I created a bug report and proposed a patch to fix it: >> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 >> >> To me it's seems to be a quite trivial patch for something that is just >> working incorrectly. It looks like "nothing is happening" :( It neither >> accepted nor denied.. > > To break back-compatibility as suggested there would be wrong. I don't think anything will "break". Mod_proxy_http silently removes some lines from the header. Right now it doesn't work as advertised. > But what you suggest makes sense if we make it a configuration > option, maybe by updating the ProxyErrorOverride directive to > enable options to treat redirects either as errors or non-errors. This sound a little weird to me. ProxyErrorOverride should not override non-errors or it should have a different name like ProxyErrorAndRedirectAndInfoOverride. We could add an option ProxyRedirectOverride. I can't think of a situation where you would want this though.. Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Hi all, I'm quite new to the list, so I'm just wondering how it works. Jeff Tharp and I created a bug report and proposed a patch to fix it: http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 To me it's seems to be a quite trivial patch for something that is just working incorrectly. It looks like "nothing is happening" :( It neither accepted nor denied.. If I need to do something to get this fixed in the 2.2 branch I would be glad to help. TIA, Bart -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Jeff Tharp wrote: > Folks, > I just wanted to add my voice to this issue. We've ran into this bug > when trying to reverse proxy a number of applications, including IBM > WebSphere Proxy Server, SAP E-Recruiting, and Roller. In each case, we > had ProxyErrorOverride set to On so we could intercept any errors from > the back-end servers. But turning this on caused us to loose cookies > set during authentication, breaking the login process. I think the > trick of setting a cookie as part of an HTTP redirect during login is > common among Java apps such as these. This has been a hurdle that has > slowed the implementation of Apache 2.2 as a reverse proxy in front of > our external-facing sites. Has a formal bug been opened on this? It > would be great to see this fixed before the next release of Apache. I didn't open a formal bug for this issue, but maybe somebody else has already done it. If not, should I create one? Bart > > Thanks, > Jeff Tharp > System Administrator > ESRI - Redlands, CA > http://www.esri.com > > From Bart van der Schans: >> Hi, >> >> The "ProxyErrorOverride On" setting is correctly catching the errors >> from the (reverse) proxied server. Only, it overrides too much IMHO. >> Right now it overrides anything that's not in the 2xx range, >> but I think >> it should allow also the 3xx range for redirects etc. >> >> A commonly used "trick" is to set a cookie with a 302 header so the >> browser gets redirected to the page which "needs" the cookie. >> When using >> ProxyErrorOverride, mod_proxy_http sets its own headers and the cookie >> is lost. >> >> The attached patch check not only for ap_is_HTTP_SUCCESS but also for >> ap_is_HTTP_REDIRECT which should solve the problem. >> >> Thanks, >> Bart van der Schans >> >> -- >> >> Hippo >> Oosteinde 11 >> 1017WT Amsterdam >> The Netherlands >> Tel +31 (0)20 5224466 >> - >> [EMAIL PROTECTED] / http://www.hippo.nl >> -- -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Plüm wrote: > >> -Ursprüngliche Nachricht- >> Von: Bart van der Schans >> >> Hi, >> >> The "ProxyErrorOverride On" setting is correctly catching the errors >> from the (reverse) proxied server. Only, it overrides too much IMHO. >> Right now it overrides anything that's not in the 2xx range, >> but I think >> it should allow also the 3xx range for redirects etc. > > I had a quick look into this and noticed the following: > > 1. It may make sense to add ap_is_HTTP_INFO to this also. Yes, that shounds like a good idea. > 2. ProxyErrorOverride is currently only honoured by mod_proxy_http, >mod_proxy_ajp ignores it. Is this intended? I don't have much experience with ajp, but being able to set a custom error is a good idea I think. > 3. This is a change in behaviour for people who use customized redirect >pages for browsers that do not support redirects (are there any?) Wouldn't that change from currently broken to working? > 4. 304 not modified responses from the backend are currently not supported >without this patch. I didn't actually tested that. Regards, Bart > > Thoughts? > > Regards > > Rüdiger > -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Mod_proxy_http ProxyErrorOverride eating cookies
Hi,
The "ProxyErrorOverride On" setting is correctly catching the errors
from the (reverse) proxied server. Only, it overrides too much IMHO.
Right now it overrides anything that's not in the 2xx range, but I think
it should allow also the 3xx range for redirects etc.
A commonly used "trick" is to set a cookie with a 302 header so the
browser gets redirected to the page which "needs" the cookie. When using
ProxyErrorOverride, mod_proxy_http sets its own headers and the cookie
is lost.
The attached patch check not only for ap_is_HTTP_SUCCESS but also for
ap_is_HTTP_REDIRECT which should solve the problem.
Thanks,
Bart van der Schans
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-
[EMAIL PROTECTED] / http://www.hippo.nl
--
--- httpd-2.2.0-orig/modules/proxy/mod_proxy_http.c 2005-11-10
16:20:05.0 +0100
+++ httpd-2.2.0/modules/proxy/mod_proxy_http.c 2006-03-31 18:02:26.0
+0200
@@ -1447,7 +1447,7 @@
* if we are overriding the errors, we can't put the content
* of the page into the brigade
*/
-if (conf->error_override == 0 || ap_is_HTTP_SUCCESS(r->status)) {
+if (conf->error_override == 0 || ap_is_HTTP_SUCCESS(r->status) ||
ap_is_HTTP_REDIRECT(r->status)) {
/* read the body, pass it to the output filters */
apr_read_type_e mode = APR_NONBLOCK_READ;
int finish = FALSE;
@@ -1549,7 +1549,7 @@
if (conf->error_override) {
/* the code above this checks for 'OK' which is what the hook expects
*/
-if (ap_is_HTTP_SUCCESS(r->status))
+if (ap_is_HTTP_SUCCESS(r->status) || ap_is_HTTP_REDIRECT(r->status))
return OK;
else {
/* clear r->status for override error, otherwise ErrorDocument
