Reload (Ctrl-r) does not recognize content-type changes




Networking: Cache
15 years ago
10 years ago


(Reporter: Jeremy M. Dolan, Assigned: gordon)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
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?

Comment 2

15 years ago
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.

Comment 3

15 years ago
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.)

Comment 4

15 years ago
> 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.

Comment 5

15 years ago
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!

Comment 6

15 years ago
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

Comment 8

15 years ago
you should just "touch" all of the files in that directory maybe.  marking
INVALID since this is just a server configuration bug.
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 9

15 years ago
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.
QA Contact: tever → cacheqa
Summary: Ctrl-r does not recognize content-type changes → Reload (Ctrl-r) does not recognize content-type changes

Comment 10

15 years ago
*** Bug 199073 has been marked as a duplicate of this bug. ***

Comment 11

15 years ago
*** Bug 129515 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
*** Bug 158034 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
*** 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. ***
Duplicate of this bug: 418771

Comment 17

10 years ago
Just thought I should point out that Apache does not believe this is their problem: . So basically this issue will exist forevermore unless the teams can agree on a solution or whose problem it really is.
You need to log in before you can comment on or make changes to this bug.