Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 45341] Apache reverse-proxy returns 304 on
 non-conditional GET request
In-Reply-To: <bug-45341-7868@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Message-Id: <20080714154935.0045E234C16C@brutus.apache.org>
Date: Mon, 14 Jul 2008 08:49:34 -0700 (PDT)

https://issues.apache.org/bugzilla/show_bug.cgi?id=45341


--- Comment #8 from Ruediger Pluem <rpluem@apache.org>  2008-07-14 08:49:33 PST ---
(In reply to comment #7)
> I know about 13.9, but I don't see where it says that all previous headers must
> be discarded. I do see that they must be updated if present, in 10.3.5: "If a

Ok I guess I wasn't clear in my explanation. I did not say that previous
headers must be discarded. The only reason I can image why the cache did a
conditional request on the backend in this situation is because the cached
entity passed the expiration date given in the cached response expires header.
So the initial check of the cache on the entity reveals that it is not fresh
enough any longer to serve directly and the freshness check with the backend
delivers a response that makes this object no longer cachable as there is no
expiration date for a request with args.

> cache uses a received 304 response to update a cache entry, the cache MUST
> update the entry to reflect any new field values given in the response." But
> there aren't any new field values given.
> 
> Section 13.9.4, in talking about max-age=0 which is specifically where I'm
> having the problem, says simply "If the server replies with 304 (Not Modified),
> then the cache can return its now validated copy to the client with a 200 (OK)
> response." 
> 
> There is (always) some ambiguity, but I don't see why mod_cache would choose to
> interpret the back-end server's plain 304 as a request to nullify the cached
> Expires header to make the resource retroactively uncacheable. And even if that
> were the best way to read the situation, 10.3.5 tells you how to recover from a
> similar problem: "If a 304 response indicates an entity not currently cached,
> then the cache MUST disregard the response and repeat the request without the
> conditional."
> 

This seems like a solution, but I guess it might be difficult to implement. So
probably expect no quick solution when going down this path.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org