Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Sun, 27 Apr 2014 10:59:31 +0200
From: dev@bcs-frankfurt.de
To: dev@httpd.apache.org
Subject: IF/ELSE- section and =?UTF-8?Q?mod=5Fcache=20errors?=
Message-ID: <36873d3bec9b677c38b9ae279dfcc102@bcs-frankfurt.de>
User-Agent: Roundcube Webmail/0.9.5

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