388141 - Caching problem with content negotiation using Accept header

Status: RESOLVED DUPLICATE of bug 633743

(Core :: Networking: Cache, defect)

Description

[u81239]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

A document at a certain address is served in two modes based on content type. What happens is:
1. Load with Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,... (normal request)
2. The HTML document that is returned does an AJAX request with Accept: application/x-fuji+xhtml+xml
3. Go to another document via a link or entering a new address (e.g. about:blank)
4. Press the BACK button.
Now the browser pops up a download dialog because it retrieves the AJAX document from its cache, even
though the browser uses the usual Accept header that I mentioned in step 1.

From Firebug’s request log:
	
	Response Headers
	Date	Mon, 02 Jul 2007 18:52:34 GMT
	Server	Apache/2.2.4 (Win32) PHP/5.2.3
	X-Powered-By	PHP/5.2.3
	Vary	Accept,Accept-Language,Accept-Encoding
	Content-Language	nl-NL
	Content-Encoding	gzip
	Content-Length	1932
	Content-Type	application/x-fuji+xhtml+xml; charset=UTF-8
	
	Request Headers
	Host	localhost:81
	User-Agent	Mozilla/5.0 (Windows; U; Windows NT 6.0; nl; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
	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	nl,en-gb;q=0.8,en-us;q=0.6,en;q=0.4,ja;q=0.2
	Accept-Encoding	gzip,deflate
	Accept-Charset	ISO-8859-1,utf-8;q=0.7,*;q=0.7
	Keep-Alive	300
	Connection	keep-alive

The response type is clearly a mismatch with the request’s Accept header, and this is a cached copy; no request is made to the server.

To make it work again and not get the incorrectly cached copy, you have to clear the cache, or manually enter the previous address
(thus avoiding the back button).

Note that if Accept is not present in the Vary header, the current behaviour is acceptable.


~Grauw

Reproducible: Always

Steps to Reproduce:
1. Go to http://obsa.grauw.nl/forum/
2. Enter about:blank in the URL bar and press ‘go’
3. Press the back button
Actual Results:  
A download dialog shows up for a file with MIME type application/x-fuji+xhtml+xml

Expected Results:  
The page that you visited previously should be loaded.

Comment 1

[u81239]

(Let me format that a little better for readability...)

A document at a certain address is served in two modes based on content type.
What happens is:

1. The document, say /test, is loaded normally in the browser, with
   Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,...
2. The HTML document, when loaded, does an AJAX request on /test with
   Accept: application/x-fuji+xhtml+xml
3. The user visits another document via a link or entering a new address.
4. The user then presses the BACK button.

Now Firefox pops up a download dialog because it retrieves the AJAX document from its cache, even though the browser uses the usual HTML Accept header that I mentioned in step 1.


~Grauw

Comment 2

[u81239]

Also, if you use View Source, you won’t get to see the HTML page’s source, but instead the AJAX request’s one.

You can also test this out by going to http://obsa.grauw.nl/forum/ and selecting View Source.

Note that the URL above is kind of a test-page for me so it might be broken occasionally. I could create a simplified testcase if you want, although it would require server-side code (i.e. needs to be a PHP file).

Comment 3

[David Arango]

This happens to me also, as Lauren said in comment #1.

Firefox loads the document from cache and it doesn't seem to check the content/type.

Comment 4

[u81239]

Not even a response from anyone at Mozilla after a year :(.

Comment 5

[Thomas K. (:tom)]

Similar to bug 132957?

Comment 6

[u81239]

That bug 132957 was fixed on 2003-05-12, and the test URL sends the correct Vary headers...

It could be though that the fix for that bug caused the current behaviour (where it caches too much instead of too little).

Comment 7

[u81239]

Probably what is missing is that Firefox’s cache only compares the request URI, and does not respect the Vary header.

Quoting from the caching section of the HTTP specification:

http://greenbytes.de/tech/webdav/rfc2616.html#caching.negotiated.responses

> When the cache receives a subsequent request whose Request-URI specifies one or
> more cache entries including a Vary header field, the cache MUST NOT use such a
> cache entry to construct a response to the new request unless all of the
> selecting request-headers present in the new request match the corresponding
> stored request-headers in the original request.

Also: http://greenbytes.de/tech/webdav/rfc2616.html#header.vary

~Laurens

Comment 8

[Patrick McManus [:mcmanus]]

vary should work here, right honza?