You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by de...@bcs-frankfurt.de on 2014/04/27 10:59:31 UTC
IF/ELSE- section and mod_cache errors
Hi,
While trying to use some of the new (and standard) functions of httpd
2.4.6, I stumbled over some errors where I need some help and which I’d
like to share and discuss.
First is the new possibility to work with IF/ELSE sections in the vhost
configs. While using some rewrite-rules inside an *ifsection, I got some
confusing error messages about trying to match “*If” in the request
path, which obviously didn’t work. Searching for this in the code led me
to server/core.c:
2360 /*
2361 * Set a dummy value so that other directives notice that
they are inside
2362 * a config section.
2363 */
2364 cmd->path = "*If";
I don’t think ‘path’ is the right place for such a dummy value, because
this breaks the pattern matching in mod_rewrite (somewhere at 3959++, if
I’m correct). I don’t know if any other module relies on this dummy
path, or if it can simply be removed?
The other bug(?) I found was while using mod_cache together with a bogus
backend sending wrong timestamps in the headers leading to
> [cache:info] [...] AH: cache: /myRequest?myQuery responded with an
uncacheable 304, retrying the request. Reason: contradiction: 304 Not
Modified, but Last-Modified modified, referer: https://my.host
resulting in deleting all entries from the cache:
> [cache:debug] [...] cache_storage.c(50): ... Removing url
user-agent... from the cache.
Ok, this way I found an error in my backend. The interesting part was
the "retrying the request”, which somehow lost the query string:
> [cache:debug] [...] cache_storage.c(664): ... cache: Key for entity
/myRequest?(null) is https://my.host:443/myRequest?, referer:
https://my.host
This time I got a valid answer of my backend, but due to the missing
query-string [(null)] with the wrong content. Worst thing is, this wrong
answer got stored by mod_cache for the full-request with the correct
query string. So for the following requests with the Query-String, I got
the answer for the request without the query-string (until cache time
was up).
Long story short - I haven't found the time to dig through the code, but
somewhere the query string got lost while "retrying the request".
Perhaps someone can give me a hint how to fix this.
regards Chriss
Re: IF/ELSE- section and mod_cache errors
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Apr 28, 2014 at 4:57 PM, Graham Leggett <mi...@sharp.fm> wrote:
> Oddly enough I encountered the same bug this week while trying to trace an unrelated uncacheable 304. +1 to the patch.
Thanks for testing/reviewing.
Commited in r1591143.
Re: IF/ELSE- section and mod_cache errors
Posted by Graham Leggett <mi...@sharp.fm>.
On 27 Apr 2014, at 7:14 PM, Yann Ylavic <yl...@gmail.com> wrote:
> Could you try the following patch?
>
> Index: modules/cache/mod_cache.c
> ===================================================================
> --- modules/cache/mod_cache.c (revision 1589129)
> +++ modules/cache/mod_cache.c (working copy)
> @@ -1200,7 +1200,7 @@ static apr_status_t cache_save_filter(ap_filter_t
> apr_table_unset(r->headers_in, "If-Range");
> apr_table_unset(r->headers_in, "If-Unmodified-Since");
>
> - ap_internal_redirect(r->uri, r);
> + ap_internal_redirect(r->unparsed_uri, r);
>
> return APR_SUCCESS;
> }
> [END]
>
> (I didn't check how r->unparsed_uri is "safe" to redirect to here, so
> that may be a temporary patch).
Oddly enough I encountered the same bug this week while trying to trace an unrelated uncacheable 304. +1 to the patch.
Regards,
Graham
--
Re: IF/ELSE- section and mod_cache errors
Posted by Chriss <de...@bcs-frankfurt.de>.
Hi Yann,
thanks for the patch, seems to be working. But I only checked that the
request hasn’t lost its query-string. I don’t know if it is "save", but
so far I’ve no further problems.
Regards Chriss
> Hi Chriss,
>
> you should create new bug(zilla) entries for these two (even if the
> second was fixed for you, there are other cases where "retrying the
> request" may not do the right thing).
>
> On Sun, Apr 27, 2014 at 10:59 AM, <de...@bcs-frankfurt.de> wrote:
>> > [cache:debug] [...] cache_storage.c(664): ... cache: Key for entity
>> /myRequest?(null) is https://my.host:443/myRequest?, referer:
>> https://my.host
>>
>> This time I got a valid answer of my backend, but due to the missing
>> query-string [(null)] with the wrong content. Worst thing is, this
>> wrong
>> answer got stored by mod_cache for the full-request with the correct
>> query
>> string. So for the following requests with the Query-String, I got the
>> answer for the request without the query-string (until cache time was
>> up).
>> Long story short - I haven't found the time to dig through the code,
>> but
>> somewhere the query string got lost while "retrying the request".
>> Perhaps
>> someone can give me a hint how to fix this.
>>
>
> Could you try the following patch?
>
> Index: modules/cache/mod_cache.c
> ===================================================================
> --- modules/cache/mod_cache.c (revision 1589129)
> +++ modules/cache/mod_cache.c (working copy)
> @@ -1200,7 +1200,7 @@ static apr_status_t cache_save_filter(ap_filter_t
> apr_table_unset(r->headers_in, "If-Range");
> apr_table_unset(r->headers_in, "If-Unmodified-Since");
>
> - ap_internal_redirect(r->uri, r);
> + ap_internal_redirect(r->unparsed_uri, r);
>
> return APR_SUCCESS;
> }
> [END]
>
> (I didn't check how r->unparsed_uri is "safe" to redirect to here, so
> that may be a temporary patch).
>
> Regards,
> Yann.
Re: IF/ELSE- section and mod_cache errors
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Chriss,
you should create new bug(zilla) entries for these two (even if the
second was fixed for you, there are other cases where "retrying the
request" may not do the right thing).
On Sun, Apr 27, 2014 at 10:59 AM, <de...@bcs-frankfurt.de> wrote:
> > [cache:debug] [...] cache_storage.c(664): ... cache: Key for entity
> /myRequest?(null) is https://my.host:443/myRequest?, referer:
> https://my.host
>
> This time I got a valid answer of my backend, but due to the missing
> query-string [(null)] with the wrong content. Worst thing is, this wrong
> answer got stored by mod_cache for the full-request with the correct query
> string. So for the following requests with the Query-String, I got the
> answer for the request without the query-string (until cache time was up).
> Long story short - I haven't found the time to dig through the code, but
> somewhere the query string got lost while "retrying the request". Perhaps
> someone can give me a hint how to fix this.
>
Could you try the following patch?
Index: modules/cache/mod_cache.c
===================================================================
--- modules/cache/mod_cache.c (revision 1589129)
+++ modules/cache/mod_cache.c (working copy)
@@ -1200,7 +1200,7 @@ static apr_status_t cache_save_filter(ap_filter_t
apr_table_unset(r->headers_in, "If-Range");
apr_table_unset(r->headers_in, "If-Unmodified-Since");
- ap_internal_redirect(r->uri, r);
+ ap_internal_redirect(r->unparsed_uri, r);
return APR_SUCCESS;
}
[END]
(I didn't check how r->unparsed_uri is "safe" to redirect to here, so
that may be a temporary patch).
Regards,
Yann.
Re: IF/ELSE- section and mod_cache errors
Posted by Eric Covener <co...@gmail.com>.
>
>
> The other bug(?) I found was while using mod_cache together with a bogus
> backend sending wrong timestamps in the headers leading to
>
> > [cache:info] [...] AH: cache: /myRequest?myQuery responded with an
> uncacheable 304, retrying the request. Reason: contradiction: 304 Not
> Modified, but Last-Modified modified, referer: https://my.host
It didn't make it into the changelog, but this is fixed in a later 2.4.x:
- * mod_cache: Stop invalidating cached responses when reval returns
304+Expires,
- trunk patch: http://svn.apache.org/r1518269
- 2.4.x patch: trunk works
- +1 covener, jim, humbedooh