Last Comment Bug 198072 - Reload (Ctrl-r) does not recognize content-type changes
: Reload (Ctrl-r) does not recognize content-type changes
Status: VERIFIED INVALID
:
Product: Core
Classification: Components
Component: Networking: Cache (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: gordon
:
Mentors:
: 129515 158034 167736 199073 230180 262002 418771 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-18 12:05 PST by Jeremy M. Dolan
Modified: 2008-02-22 04:33 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
NSPR_LOG_MODULES=nsHttp:5 (32.43 KB, text/plain)
2003-03-18 16:36 PST, Jeremy M. Dolan
no flags Details

Description Jeremy M. Dolan 2003-03-18 12:05:33 PST
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
Comment 1 Boris Zbarsky [:bz] 2003-03-18 12:32:12 PST
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 gordon 2003-03-18 13:21:32 PST
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 Darin Fisher 2003-03-18 15:11:32 PST
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 Jeremy M. Dolan 2003-03-18 15:52:32 PST
> 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 Darin Fisher 2003-03-18 16:07:43 PST
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 Jeremy M. Dolan 2003-03-18 16:36:50 PST
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.
Comment 7 Boris Zbarsky [:bz] 2003-03-18 16:47:46 PST
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....)
Comment 8 Darin Fisher 2003-03-19 11:38:10 PST
you should just "touch" all of the files in that directory maybe.  marking
INVALID since this is just a server configuration bug.
Comment 9 benc 2003-03-19 14:05:33 PST
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.
Comment 10 gordon 2003-03-24 19:50:58 PST
*** Bug 199073 has been marked as a duplicate of this bug. ***
Comment 11 gordon 2003-03-28 17:04:42 PST
*** Bug 129515 has been marked as a duplicate of this bug. ***
Comment 12 benc 2003-04-09 13:54:39 PDT
*** Bug 158034 has been marked as a duplicate of this bug. ***
Comment 13 benc 2003-04-09 13:55:52 PDT
*** Bug 167736 has been marked as a duplicate of this bug. ***
Comment 14 Matthias Versen [:Matti] 2004-06-22 09:29:38 PDT
*** Bug 230180 has been marked as a duplicate of this bug. ***
Comment 15 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-28 17:18:30 PDT
*** Bug 262002 has been marked as a duplicate of this bug. ***
Comment 16 Matthias Versen [:Matti] 2008-02-20 23:51:40 PST
*** Bug 418771 has been marked as a duplicate of this bug. ***
Comment 17 cyaugin 2008-02-22 04:33:27 PST
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.

Note You need to log in before you can comment on or make changes to this bug.