Closed Bug 198072 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Networking: Cache, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: jmd, Assigned: gordon)

References

Details

Attachments

(1 file)

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!
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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → VERIFIED
QA Contact: tever → cacheqa
Summary: Ctrl-r does not recognize content-type changes → Reload (Ctrl-r) does not recognize content-type changes
*** 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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: