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.
Well... the server is not reporting the document as changed, is it? So it has
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
(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
upload /tmp/log.txt to this bug
if you could do this it would be most appreciated. thx in advance!
Created attachment 117661 [details]
This is a log of:
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
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
you should just "touch" all of the files in that directory maybe. marking
INVALID since this is just a server configuration bug.
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. ***
*** Bug 418771 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.