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, <[email protected]> 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.
