You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2005/06/06 15:01:00 UTC
Re: problems w/ geronimo wiki (cache???)
[Bringing dev@httpd into the discussion; we just activated
mod_disk_cache from 2.1-head on the apache wiki and it is broken.]
Geir Magnusson Jr. wrote:
> We're having problems now getting to the geronimo wiki
>
> http://wiki.apache.org/geronimo/
>
> some people get content, some people get nothing. Any ideas?
mod_cache is returning:
HTTP/1.1 304 Not Modified
Date: Mon, 06 Jun 2005 12:56:11 GMT
Server: Apache/2.1.5-dev (Unix)
Connection: close
to ordinary non-conditional GET requests. The result is obviously a
blank page in the browser.
So obviously mod_cache is not dealing correctly with 304 responses from
the back-end, and is therefore rather useless at the moment. I've
turned it off on the wiki.
Any suggestions from dev@httpd?
Joshua.
Re: problems w/ geronimo wiki (cache???)
Posted by Joshua Slive <jo...@slive.ca>.
Justin Erenkrantz wrote:
> On Mon, Jun 06, 2005 at 03:40:41PM +0200, Sander Striker wrote:
>
>>Justin, how's your stack of round tuits?
>
>
> Not plentiful at the moment. =(
>
> Can we keep the caching running on port 81 on ajax? That'll make it easier to
> debug if I do get some time. We'd really need to see what the
> request/response chain is. I thought someone said that MoinMoin doesn't know
> how to handle 304s - if so, this doesn't make much sense. -- justin
I've setup a duplicate vhost on 81 with the cache enabled. (I did this
on the live site without checking anything into svn.) This URL currently
shows the problem:
http://wiki.apache.org:81/geronimo/FrontPage
I can't say I understand exactly what the problem is either. But moin
is, indeed, returning 304s.
Joshua.
Re: problems w/ geronimo wiki (cache???)
Posted by Sander Striker <st...@apache.org>.
Justin Erenkrantz wrote:
> On Mon, Jun 06, 2005 at 03:40:41PM +0200, Sander Striker wrote:
[...]
> Can we keep the caching running on port 81 on ajax? That'll make it easier to
> debug if I do get some time. We'd really need to see what the
> request/response chain is. I thought someone said that MoinMoin doesn't know
> how to handle 304s - if so, this doesn't make much sense. -- justin
Yes, that's a good point. Where is this 304 coming from if not from Moin?
The core server code nor the caching code generate a 304 when the request
is non-conditional.
Sander
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Jun 06, 2005 at 03:40:41PM +0200, Sander Striker wrote:
> Justin, how's your stack of round tuits?
Not plentiful at the moment. =(
Can we keep the caching running on port 81 on ajax? That'll make it easier to
debug if I do get some time. We'd really need to see what the
request/response chain is. I thought someone said that MoinMoin doesn't know
how to handle 304s - if so, this doesn't make much sense. -- justin
Re: problems w/ geronimo wiki (cache???)
Posted by Joshua Slive <jo...@slive.ca>.
Dirk-Willem van Gulik wrote:
>
> On Mon, 6 Jun 2005, Sander Striker wrote:
>
>
>>I could have sworn we had solved this a few months ago. I've seen this
>>working with 2.1.4-dev, but I'd need to track back what rev. I don't
>>expect to be able to look at this before wednesday :/
>
>
> When I get bitten by this - I find that adding an exatra '/' virtually
> always solves the 'problem' and gives me the page.
Well, that's just a way to break through the cache. Adding ?foo=bar
will almost always work as well.
But anyway, I'll leave this disabled on the wiki until someone has a
chance to look at it. (Sorry, I'm not volunteering.)
Joshua.
Re: problems w/ geronimo wiki (cache???)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 6 Jun 2005, Sander Striker wrote:
> I could have sworn we had solved this a few months ago. I've seen this
> working with 2.1.4-dev, but I'd need to track back what rev. I don't
> expect to be able to look at this before wednesday :/
When I get bitten by this - I find that adding an exatra '/' virtually
always solves the 'problem' and gives me the page.
DW.
Re: problems w/ geronimo wiki (cache???)
Posted by Sander Striker <st...@apache.org>.
Joshua Slive wrote:
> [Bringing dev@httpd into the discussion; we just activated
> mod_disk_cache from 2.1-head on the apache wiki and it is broken.]
>
> Geir Magnusson Jr. wrote:
>
>> We're having problems now getting to the geronimo wiki
>>
>> http://wiki.apache.org/geronimo/
>>
>> some people get content, some people get nothing. Any ideas?
>
>
> mod_cache is returning:
> HTTP/1.1 304 Not Modified
> Date: Mon, 06 Jun 2005 12:56:11 GMT
> Server: Apache/2.1.5-dev (Unix)
> Connection: close
>
> to ordinary non-conditional GET requests. The result is obviously a
> blank page in the browser.
>
> So obviously mod_cache is not dealing correctly with 304 responses from
> the back-end, and is therefore rather useless at the moment. I've
> turned it off on the wiki.
>
> Any suggestions from dev@httpd?
I could have sworn we had solved this a few months ago. I've seen this
working with 2.1.4-dev, but I'd need to track back what rev. I don't
expect to be able to look at this before wednesday :/
Justin, how's your stack of round tuits?
Sander
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, June 7, 2005 7:14 PM -0400 Joshua Slive <jo...@slive.ca>
wrote:
> Go for it. What are our production servers for if not testing httpd
> patches ;-)
As a data point (and one I think you alluded to earlier), the LA on the box
was about 30 before I turned on the cache. It's now settled down to around
5-6. So, yah, it'd be a good idea to get this working. ;-) -- justin
Re: problems w/ geronimo wiki (cache???)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 7 Jun 2005, Justin Erenkrantz wrote:
> Perhaps we should try again to stick it into production? Heh. -- justin
Go for it. What are our production servers for if not testing httpd
patches ;-)
Joshua.
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, June 7, 2005 2:01 PM -0700 Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> --On Tuesday, June 7, 2005 1:50 PM -0700 Justin Erenkrantz
> <ju...@erenkrantz.com> wrote:
>
>> to be a better way. For now, I'll commit a fix that matches what we did
>> with mod_proxy; but this pattern keeps emerging. -- justin
>
> I'm not going to commit it yet. However, I'm building a new httpd on
> ajax with the following patch. -- justin
The patch needed one more tweak to set the status before calling the
filters. So far, it looks okay on ajax off: http://wiki.apache.org:81/
Perhaps we should try again to stick it into production? Heh. -- justin
Index: mod_cgi.c
===================================================================
--- mod_cgi.c (revision 188864)
+++ mod_cgi.c (working copy)
@@ -921,7 +921,18 @@
int ret;
if ((ret = ap_scan_script_header_err_brigade(r, bb, sbuf))) {
- return log_script(r, conf, ret, dbuf, sbuf, bb, script_err);
+ ret = log_script(r, conf, ret, dbuf, sbuf, bb, script_err);
+
+ /* Set our status. */
+ r->status = ret;
+
+ /* Pass EOS bucket down the filter chain. */
+ apr_brigade_cleanup(bb);
+ b = apr_bucket_eos_create(c->bucket_alloc);
+ APR_BRIGADE_INSERT_TAIL(bb, b);
+ ap_pass_brigade(r->output_filters, bb);
+
+ return ret;
}
location = apr_table_get(r->headers_out, "Location");
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, June 7, 2005 1:50 PM -0700 Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> to be a better way. For now, I'll commit a fix that matches what we did
> with mod_proxy; but this pattern keeps emerging. -- justin
I'm not going to commit it yet. However, I'm building a new httpd on ajax
with the following patch. -- justin
Index: mod_cgi.c
===================================================================
--- mod_cgi.c (revision 188838)
+++ mod_cgi.c (working copy)
@@ -921,7 +921,15 @@
int ret;
if ((ret = ap_scan_script_header_err_brigade(r, bb, sbuf))) {
- return log_script(r, conf, ret, dbuf, sbuf, bb, script_err);
+ ret = log_script(r, conf, ret, dbuf, sbuf, bb, script_err);
+
+ /* Pass EOS bucket down the filter chain. */
+ apr_brigade_cleanup(bb);
+ b = apr_bucket_eos_create(c->bucket_alloc);
+ APR_BRIGADE_INSERT_TAIL(bb, b);
+ ap_pass_brigade(r->output_filters, bb);
+
+ return ret;
}
location = apr_table_get(r->headers_out, "Location");
Re: problems w/ geronimo wiki (cache???)
Posted by r....@t-online.de.
Justin Erenkrantz wrote:
> --On Wednesday, June 8, 2005 12:09 AM +0200 Sander Striker
> <st...@apache.org> wrote:
>
>>> Yes you are right I forgot this. So I think this would be better:
>
>
> FWIW, I *think* the patch should return result rather than the value of
> ap_pass_brigade. (Although I have a feeling that might not be correct,
> either.)
>
I think we should pass the value of ap_pass_brigade, because if I remember myself
correctly the CACHE_SAVE filter of mod_cache may transform a 304 into a 200 if the
304 was the response to an originally stale cache entry, that turned out to be fresh
after revalidation.
Around 540 in mod_cache.c
/* Did we have a stale cache entry that really is stale? */
if (cache->stale_handle) {
if (r->status == HTTP_NOT_MODIFIED) {
/* Oh, hey. It isn't that stale! Yay! */
cache->handle = cache->stale_handle;
info = &cache->handle->cache_obj->info;
rv = OK;
}
Around 694 in mod_cache.c
/* Did we just update the cached headers on a revalidated response?
*
* If so, we can now decide what to serve to the client. This is done in
* the same way as with a regular response, but conditions are now checked
* against the cached or merged response headers.
*/
if (rv == APR_SUCCESS && cache->stale_handle) {
apr_bucket_brigade *bb;
apr_bucket *bkt;
int status;
bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
[..cut..]
Regards
Rüdiger
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, June 8, 2005 12:09 AM +0200 Sander Striker
<st...@apache.org> wrote:
>> Yes you are right I forgot this. So I think this would be better:
FWIW, I *think* the patch should return result rather than the value of
ap_pass_brigade. (Although I have a feeling that might not be correct,
either.)
> I'm pondering if we shouldn't just abort() right here (wrap it in debug
> defines
> maybe) and fix all the core modules.
>
> OTOH, we can decide the modules aren't broken at all. Whatever we do will
> require some documenting on what a module should and should not do.
Yah, I don't really know what the right thing to do is here. I know that
when we did the mod_proxy fix, we had agreed that the handler was broken
and it should always be sending an EOS. My gut still says that's right;
but the failure case is downright nasty. -- justin
Re: problems w/ geronimo wiki (cache???)
Posted by Sander Striker <st...@apache.org>.
r.pluem@t-online.de wrote:
>
> Justin Erenkrantz wrote:
>
>>--On Tuesday, June 7, 2005 11:42 PM +0200 r.pluem@t-online.de wrote:
>>
>>
>>>Sorry, if this is a stupid quickshot, but what about something like:
>>
>>
>>Nope, it's not stupid as that's about the only sane place I can think of
>>sticking it as well. The only catch is that if a handler exits this
>>way, it probably means that r->status isn't correct either. So, perhaps
>>we also set r->status explicitly in this additional code path. -- justin
> Yes you are right I forgot this. So I think this would be better:
>
> --- config.c.orig 2005-05-26 10:35:57.000000000 +0200
> +++ config.c 2005-06-07 23:54:17.000000000 +0200
> @@ -375,6 +375,18 @@ AP_CORE_DECLARE(int) ap_invoke_handler(r
> "handler \"%s\" not found for: %s", r->handler, r->filename);
> }
>
> + if (!r->eos_sent && (result != DECLINED)) {
I'm pondering if we shouldn't just abort() right here (wrap it in debug defines
maybe) and fix all the core modules.
OTOH, we can decide the modules aren't broken at all. Whatever we do will
require some documenting on what a module should and should not do.
Sander
Re: problems w/ geronimo wiki (cache???)
Posted by r....@t-online.de.
Justin Erenkrantz wrote:
> --On Tuesday, June 7, 2005 11:42 PM +0200 r.pluem@t-online.de wrote:
>
>> Sorry, if this is a stupid quickshot, but what about something like:
>
>
> Nope, it's not stupid as that's about the only sane place I can think of
> sticking it as well. The only catch is that if a handler exits this
> way, it probably means that r->status isn't correct either. So, perhaps
> we also set r->status explicitly in this additional code path. -- justin
>
Yes you are right I forgot this. So I think this would be better:
--- config.c.orig 2005-05-26 10:35:57.000000000 +0200
+++ config.c 2005-06-07 23:54:17.000000000 +0200
@@ -375,6 +375,18 @@ AP_CORE_DECLARE(int) ap_invoke_handler(r
"handler \"%s\" not found for: %s", r->handler, r->filename);
}
+ if (!r->eos_sent && (result != DECLINED)) {
+ apr_bucket_brigade *bb;
+ apr_bucket *e;
+
+ r->status = result;
+ bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
+ e = apr_bucket_eos_create(r->connection->bucket_alloc);
+ APR_BRIGADE_INSERT_TAIL(bb, e);
+
+ return ap_pass_brigade(r->output_filters, bb);
+ }
+
return result == DECLINED ? HTTP_INTERNAL_SERVER_ERROR : result;
}
Regards
Rüdiger
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, June 7, 2005 11:42 PM +0200 r.pluem@t-online.de wrote:
> Sorry, if this is a stupid quickshot, but what about something like:
Nope, it's not stupid as that's about the only sane place I can think of
sticking it as well. The only catch is that if a handler exits this way,
it probably means that r->status isn't correct either. So, perhaps we also
set r->status explicitly in this additional code path. -- justin
Re: problems w/ geronimo wiki (cache???)
Posted by r....@t-online.de.
Justin Erenkrantz wrote:
[..cut..]
>
> We really need a way to generically solve this problem to ensure that an
> EOS is always sent for every request when the request's filter chains
> are still active.
>
Sorry, if this is a stupid quickshot, but what about something like:
--- config.c.orig 2005-05-26 10:35:57.000000000 +0200
+++ config.c 2005-06-07 23:38:36.000000000 +0200
@@ -375,6 +375,17 @@ AP_CORE_DECLARE(int) ap_invoke_handler(r
"handler \"%s\" not found for: %s", r->handler, r->filename);
}
+ if (!r->eos_sent && (result != DECLINED)) {
+ apr_bucket_brigade *bb;
+ apr_bucket *e;
+
+ bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
+ e = apr_bucket_eos_create(r->connection->bucket_alloc);
+ APR_BRIGADE_INSERT_TAIL(bb, e);
+
+ return ap_pass_brigade(r->output_filters, bb);
+ }
+
return result == DECLINED ? HTTP_INTERNAL_SERVER_ERROR : result;
}
[..cut..]
Regards
Rüdiger
Re: problems w/ geronimo wiki (cache???)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, June 6, 2005 4:01 PM +0200 Sander Striker <st...@apache.org>
wrote:
>> So this is the same problem reported here:
>> http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/%3c428F94
>> BE.1010705@gmx.de%3e
>>
>> which Sander said he was working on. Any progress? The cache is kind
>> of useless at the moment, dogfood-wise.
>
> In short, with details left out: The problem was that the 304 was not
> propagated down into the filterstack; leaving the CACHE_SAVE filter no
> chance to morph the 304 into a full response in case the client did a
> non-conditional request.
>
> This problem was solved, but apparently we have regressed.
So, I had a chance to look at it. It's the same problem but in a different
module. cgi_handler never sends an EOS down the filter chain when it gets
a 304 (anything non-200). The problem above was that mod_proxy wouldn't
send an EOS either in this same case.
We really need a way to generically solve this problem to ensure that an
EOS is always sent for every request when the request's filter chains are
still active.
The short-term solution is to get cgi_handler to send the EOS in
cgi_handler (circa line 924 in the log_script path); but there really has
to be a better way. For now, I'll commit a fix that matches what we did
with mod_proxy; but this pattern keeps emerging. -- justin
Re: problems w/ geronimo wiki (cache???)
Posted by Sander Striker <st...@apache.org>.
Joshua Slive wrote:
>
>
> Joshua Slive wrote:
>
>> mod_cache is returning:
>> HTTP/1.1 304 Not Modified
>> Date: Mon, 06 Jun 2005 12:56:11 GMT
>> Server: Apache/2.1.5-dev (Unix)
>> Connection: close
>>
>> to ordinary non-conditional GET requests. The result is obviously a
>> blank page in the browser.
>
>
> So this is the same problem reported here:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/%3c428F94BE.1010705@gmx.de%3e
>
> which Sander said he was working on. Any progress? The cache is kind
> of useless at the moment, dogfood-wise.
In short, with details left out: The problem was that the 304 was not
propagated down into the filterstack; leaving the CACHE_SAVE filter no
chance to morph the 304 into a full response in case the client did a
non-conditional request.
This problem was solved, but apparently we have regressed.
Sander
Re: problems w/ geronimo wiki (cache???)
Posted by Joshua Slive <jo...@slive.ca>.
Joshua Slive wrote:
> mod_cache is returning:
> HTTP/1.1 304 Not Modified
> Date: Mon, 06 Jun 2005 12:56:11 GMT
> Server: Apache/2.1.5-dev (Unix)
> Connection: close
>
> to ordinary non-conditional GET requests. The result is obviously a
> blank page in the browser.
So this is the same problem reported here:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200505.mbox/%3c428F94BE.1010705@gmx.de%3e
which Sander said he was working on. Any progress? The cache is kind
of useless at the moment, dogfood-wise.
Joshua.