Load a .rss file sent as text/plain. Edit .htaccess (or whatever) to send it as text/xml. Ctrl-R (or presumably, the reload button) in mozilla. File still shown as plain text, instead of XML view. Shift-Ctrl-R will load XML view. Gecko/20030317 Phoenix/0.5
Well... the server is not reporting the document as changed, is it? So it has not changed. Darin, this has come up before. Isn't this what the Vary header is all about?
It would also be useful to know what the revalidation settings are in the cache pref panel Everytime, When Out of Date, Once Per Session, Never). I'm also presuming this is an http: url, not a file: url.
reporter: are you using a proxy server? this sounds like it could be a proxy server issue related to the request headers we send on reload. some older HTTP/1.0 proxy servers do not understand the headers we send when the user presses reload. (bz: vary header wouldn't impact meaning of reload; it only impacts what we do on a normal page load.) (gordon: cache validation prefs don't apply when user presses reload; they only apply to normal page load.)
> Well... the server is not reporting the document as changed I would assume when it sends the same checksum header, it also sends the changed Content-type header. Mozilla should notice this, take the old content, and render it in this new fashion. > reporter: are you using a proxy server? this sounds like it could be a proxy Sorry, but no. It's a direct connection.
jmd: ok, then what we need is to see a HTTP log. can you do the following: bash$ export NSPR_LOG_MODULES=nsHttp:5 bash$ export NSPR_LOG_FILE=/tmp/log.txt bash$ mozilla reproduce problem exit mozilla upload /tmp/log.txt to this bug if you could do this it would be most appreciated. thx in advance!
Created attachment 117661 [details] NSPR_LOG_MODULES=nsHttp:5 This is a log of: Start Load rss page as text/plain Set content type to text/xml on server ^R (still rendered as text) shift-^R (rendered as unstyled XML) Looks like Apache isn't sending the content type on a 304. Perhaps an Apache bug? What's the spec say to do for a changed content type? Needs to be indicated in some way, I'm sure.
From RFC 2616, section "14.17 Content-Type": The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. From the same, section "10.3.5 304 Not Modified": The 304 response MUST NOT contain a message-body. And then further in the same section: The response MUST include the following header fields: - Date, unless its omission is required by section 14.18.1 If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly. - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. So apache's behavior is perfectly correct, assuming that sending 304 is correct. Whether it's correct to send 304 is arguable; I'd think that editing a .htaccess file would auto-modify all things in that dir (eg that can change whether SSI is applied....)
you should just "touch" all of the files in that directory maybe. marking INVALID since this is just a server configuration bug.
VERIFIED/invalid: I think this purely depends on how apache caches the local last-modified information. It sounds like If-Modified-since access some cached data, where a normal request forces a full set of disk access activities.
*** Bug 199073 has been marked as a duplicate of this bug. ***
*** Bug 129515 has been marked as a duplicate of this bug. ***
*** Bug 158034 has been marked as a duplicate of this bug. ***
*** Bug 167736 has been marked as a duplicate of this bug. ***
*** Bug 230180 has been marked as a duplicate of this bug. ***
*** Bug 262002 has been marked as a duplicate of this bug. ***
Just thought I should point out that Apache does not believe this is their problem: http://issues.apache.org/bugzilla/show_bug.cgi?id=44470 . So basically this issue will exist forevermore unless the teams can agree on a solution or whose problem it really is.