Mailing List Archive: Apache: Bugs

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request

Index | Next | Previous | View Threaded

bugzilla at apache

Jul 4, 2008, 6:37 AM

Post #1 of 11 (724 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request

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

--- Comment #1 from Jan Kirschner <JKirschner[at]firma.seznam.cz> 2008-07-04 06:37:58 PST ---
Works fine, when the server.aa sends Expires: xxxx in the 304 respose -
proxy.aa returns 200 and the cached content. But still...

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 13, 2008, 10:34 AM

Post #2 of 11 (638 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #2 from Nathan Hamblen <nathan[at]technically.us> 2008-07-13 10:34:26 PST ---
I'm also experiencing this bug, using Apache/2.2.8 with mod_cache and
mod_disk_cache over an AJP reverse proxy of an Apache Wicket application;
Wicket does not set Expire headers when responding with 304 (which works fine
without the cache on). Here is my TCP trace:

-------
GET /resources/com.typeturner.Typeturner/image?name=kitchen1 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us)
AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Cache-Control: max-age=0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: Typeturner_USER=nathan; Typeturner_AUTH=xxxx; JSESSIONID=xxxx
Connection: keep-alive
Host: technically.us

HTTP/1.1 304 NOT_MODIFIED
Date: Sun, 13 Jul 2008 13:23:28 GMT
Server: Server: Jetty(6.0.x)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Vary: Accept-Encoding
-------

However, this failing behavior only seems to occur when a query string is
present in the URL. Otherwise, mod_cache seems to perform an unconditional GET
on the proxied server, and pass along that response to the client:

-------
GET /resources/org.apache.wicket.Application/eat-photo HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us)
AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Cache-Control: max-age=0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: Typeturner_USER=nathan; Typeturner_AUTH=xxxx; JSESSIONID=xxxx
Connection: keep-alive
Host: technically.us

HTTP/1.1 200 OK
Date: Sun, 13 Jul 2008 14:44:56 GMT
Server: Server: Jetty(6.0.x)
Expires: Sun, 20 Jul 2008 14:44:14 GMT
Cache-Control: max-age=604800
Vary: Accept-Encoding
Content-Encoding: gzip
Last-Modified: Wed, 09 Jul 2008 12:22:57 GMT
Content-Length: 40831
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg
[....]
-------

To work around the problem, I've patched Wicket to set an Expires header when
responding with 304 and I'll offer that to the project as an improvement, but I
do think mod_cache is behaving incorrectly.

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 13, 2008, 10:35 AM

Post #3 of 11 (640 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

Nathan Hamblen <nathan[at]technically.us> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |nathan[at]technically.us

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 13, 2008, 12:06 PM

Post #4 of 11 (642 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

Ruediger Pluem <rpluem[at]apache.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO

--- Comment #3 from Ruediger Pluem <rpluem[at]apache.org> 2008-07-13 12:06:19 PST ---
(In reply to comment #1)
> Works fine, when the server.aa sends Expires: xxxx in the 304 respose -
> proxy.aa returns 200 and the cached content. But still...
>

Do your requests contain query strings like the ones of the second reporter?

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 13, 2008, 12:17 PM

Post #5 of 11 (636 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #4 from Ruediger Pluem <rpluem[at]apache.org> 2008-07-13 12:17:34 PST ---
(In reply to comment #2)
> I'm also experiencing this bug, using Apache/2.2.8 with mod_cache and
> mod_disk_cache over an AJP reverse proxy of an Apache Wicket application;
> Wicket does not set Expire headers when responding with 304 (which works fine
> without the cache on). Here is my TCP trace:
>

This is somehow an error of Wicket. Why?
Because requests with query strings are only cacheable if the response contains
an expires date. So I can only think of the following situation in your case:

1. Request with query string is not cached
2. Response is 200 and contains expire date => Request/response is cached.
3. Subsequent request within the expiration time are served without problems
as mod_cache does not sent conditional requests to the backend.
4. After the expiration date if passed mod_cache sents a *conditional* request
to
the backend even if the original request was unconditional.
5. The response is 304 *without* expiration date, which tells the cache that
the
cached response is unusable and needs to be ejected.

This is an error of wicket as a 304 response should contain all headers that
are relevant for caching.

The cache is in a problematic situation here:

1. Sending a 304 is wrong, because the original request was unconditional.
2. Serving the contents from the cache is not allowed since the backend told
the
cache that the current contents of the cache is invalid without delivering
new content.

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 13, 2008, 2:44 PM

Post #6 of 11 (630 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #5 from Nathan Hamblen <nathan[at]technically.us> 2008-07-13 14:44:20 PST ---
(Jan does appear to be requesting also with a query string,
http://server.aa/creative?bannerId=618167&seqNo=4&set=sec)

Yes, that is the sequence I have figured. But I'm not sure that the 304
response without an Expires header is strictly erroneous. If that is clear in
the protocol I can file it as a bug in Wicket instead of an improvement, but I
haven't been able to find anything definitive.

I don't see how a plain 304 "tells the cache that the cached response is
unusable and needs to be ejected". The cache has asked the back end if the
resource has changed since a date. The answer is no, and the cache would do
better to serve what it has. Relaying the 304 brings about a definite client
error condition that would not have occurred without the cache.

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 14, 2008, 12:21 AM

Post #7 of 11 (619 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #6 from Ruediger Pluem <rpluem[at]apache.org> 2008-07-14 00:21:10 PST ---
(In reply to comment #5)
> (Jan does appear to be requesting also with a query string,
> http://server.aa/creative?bannerId=618167&seqNo=4&set=sec)
>
> Yes, that is the sequence I have figured. But I'm not sure that the 304
> response without an Expires header is strictly erroneous. If that is clear in
> the protocol I can file it as a bug in Wicket instead of an improvement, but I
> haven't been able to find anything definitive.
>
> I don't see how a plain 304 "tells the cache that the cached response is
> unusable and needs to be ejected". The cache has asked the back end if the

This is because of 13.9 in RFC2616

> resource has changed since a date. The answer is no, and the cache would do

The resource hasn't changed, but its metadata has as no expires header is
delivered anymore.

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 14, 2008, 5:57 AM

Post #8 of 11 (602 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #7 from Nathan Hamblen <nathan[at]technically.us> 2008-07-14 05:57:57 PST ---
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
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."

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 14, 2008, 8:49 AM

Post #9 of 11 (604 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #8 from Ruediger Pluem <rpluem[at]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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 14, 2008, 9:39 AM

Post #10 of 11 (602 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #9 from Nathan Hamblen <nathan[at]technically.us> 2008-07-14 09:39:01 PST ---
"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."

It hasn't passed the expiration time it my testing. I would say it's requesting
a refresh because Safari specified "max-age:0", and mod_cache is discarding the
known, future expiration time. That is the first thing I would fix, and then
the recovery procedure for when the expiration date has passed. (I never expect
quick resolutions, or any resolutions, unless I'm providing a patch and it's
small, so no worries there. I'm just trying to document the existing behavior
and determine what would be the best correct behavior, for other people that
run into the problem or that might want to fix it.)

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

bugzilla at apache

Jul 21, 2008, 12:32 AM

Post #11 of 11 (561 views)
Permalink

[Bug 45341] Apache reverse-proxy returns 304 on non-conditional GET request [In reply to]

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

--- Comment #10 from Jan Kirschner <JKirschner[at]firma.seznam.cz> 2008-07-21 00:32:47 PST ---
(In reply to comment #3)
>
> Do your requests contain query strings like the ones of the second reporter?
>

Yes they do. ... There is a mistake in my (manually modified) http trace - all
request strings were the same. Sorry for long response time - I was on my
holiday last week.

--
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[at]httpd.apache.org
For additional commands, e-mail: bugs-help[at]httpd.apache.org

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com