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, <d...@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.
