On Mon, Apr 28, 2014 at 4:57 PM, Graham Leggett 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.
On 27 Apr 2014, at 7:14 PM, Yann Ylavic 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)
>
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
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, wrote:
> > [cache:debug] [...] cache_storage.c(664): ... cache: Key for ent
>
>
> 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, b
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 insid
