Bug 7396 – links in this site come up as source code - sometimes

• Status: RESOLVED
• Resolution: INVALID
• Component: Evangelism

[the codist]

The index page and subpages in this site come up as plain html text the first time you click on it. No DOM at all. Subsequent reloads correctly display the content. However a later view of the page may do it again.

This does not happen on any other browser I tried. All the pages are strict XHTML 1.0 and validated.

Can anyone reproduce? Any clue what's going on here?

Other sites from the same server (I control it) come up fine, only this one has the problem. This is the only strict XHTML 1.0 site however.

[Joost de Valk (AlthA)]

I cannot confirm this behavior, neither in the latest nightly, nor in released Safari. Could you give some more information on what you're doing whent his happens?

[the codist]

NOthing special, I just go to the site, just tried it again this morning, still happens. Perhaps its some preference setting or environment issue. I do have pithhelmet, I will try this evening with a clean version.

[the codist]

I just did a Reset Safari... and now the site comes up normally. Pithhelmet on or off didn't matter but when I cleared out everything it seemed to work normally again. Some cached item must have been the cause but now I don't know what it was.

[the codist]

After using safari for a couple hours, I retried the site and again got the source code display. Resetting Safari again cleared the issue. Some timing thing or cache item is causing this, but still can't pin down any specific cause.

[Salman Abdulali]

I frequently see the same problem at projecteuclid.org.  Examples of pages where this occurs frequently enough to be annoying are

http://projecteuclid.org/jdg
http://projecteuclid.org/annm

[Alex Taylor]

Intermittant problem, original submitters link appears to be down, reproducable with the links contained Comment #5.

Haven't managed to find a common cause, the XHTML seems to just get dumped onto the screen in text/plain on some renders. Occured first when I used 'Back' to go back to the cached version in history.

[tim bates]

(In reply to comment #5)
> I frequently see the same problem at projecteuclid.org
> http://projecteuclid.org/jdg
> http://projecteuclid.org/annm

Loaded both 20 times each. no problems with 2.0.4 (419.3)  revision 15498

[Salman Abdulali]

(In reply to comment #7)

The problem is still around in 2.0.4 (419.3). Since it is intermittent, it may not always be visible.

[Peter Pedaci]

Same thing at www.liebedeinestadt.de
No way to pin it down to a specific reason, can't reproduce the error on the pages linked in comment #5, though... 

[David Kilzer (:ddkilzer)]

Need to capture a packet trace of getting a page returned as source code.  It may simply be a server-side issue.  Does the same thing happen in browsers other than Safari, or just in Safari?

[Peter Pedaci]

As far as I've been testing it (and that was quite a bit) it only appeared with Safari. Could indeed be a server side thing, though...

[the codist]

When I originally got this error I tried extensively in Firefox but never got the same behavior. The original site I referenced is different now. Don't use it for testing.

[David Kilzer (:ddkilzer)]

Do any of you have Haxies or Input Managers installed like SafariStand, PithHelment or Saft?

http://www.unsanity.com/haxies/ape
http://pimpmysafari.com/

If so, could you try removing/disabling them, then see if the problem still occurs?

[the codist]

When I tested the bug originally, I tested with both pith helmet installed and not, didn't make a difference.

[Peter Pedaci]

I have Application Enhancer installed, but since I can't reproduce the error at the moment, I can't either test it with AE disabled... will try again and ask my colleague who did see the error too, if he had AE installed.

[Salman Abdulali]

(In reply to comment #13)

I have none of these installed, but regularly run across this problem. A typical (but not always reproducible) experience is:

1.  Go to http://projecteuclid.org/jdg . Page displays correctly.
2.  Visit some other web page.
3.  Now go back to http://projecteuclid.org/jdg . See the source code being displayed.
4.  Click reload. Page displays normally.

[David Kilzer (:ddkilzer)]

(In reply to comment #16)
> A typical (but not always reproducible) experience is:
> 
> 1.  Go to http://projecteuclid.org/jdg . Page displays correctly.
> 2.  Visit some other web page.
> 3.  Now go back to http://projecteuclid.org/jdg . See the source code being
> displayed.
> 4.  Click reload. Page displays normally.

W00t!  I just reproduced this!  Confirmed using locally-built debug build of WebKit r18845 with Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127).

[David Kilzer (:ddkilzer)]

Steps to reproduce:

1. Open Safari/WebKit.
2. Empty cache (cmd-option-E).
3. Paste URL in to address bar and hit Enter: http://projecteuclid.org/jdg
4. Paste same URL in to address bar and hit Enter again: http://projecteuclid.org/jdg

Expected results:

Page is rendered as HTML.

Actual results:

Page is rendered as source!

Regression:

Haven't tested shipping Safari yet.

Notes:

None.

Wild speculation:

This appears to have something to do with the back/forward cache and page loading.  It may be specific to XHTML documents, too.

[David Kilzer (:ddkilzer)]

(In reply to comment #18)
> Regression:
> 
> Haven't tested shipping Safari yet.

Same issue occurs in shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127).

> Wild speculation:
> 
> This appears to have something to do with the back/forward cache and page
> loading.  It may be specific to XHTML documents, too.

May also have something to do with redirects.

[David Kilzer (:ddkilzer)]

Here's what happens as the HTTP protocol level (assuming you're starting with an empty browser cache--use Cmd-Opt-E to empty it):

1. Safari requests http://projecteuclid.org/jdg

GET /jdg HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Safari/419.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Host: projecteuclid.org

2. Web server returns response:

HTTP/1.1 200 OK
Date: Mon, 15 Jan 2007 00:31:54 GMT
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Last-Modified: Fri, 01 Oct 2004 16:17:43 GMT
ETag: "12d85a-214-415d8327"
Accept-Ranges: bytes
Content-Length: 532
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

3. JavaScript in response causes Safari to load: http://projecteuclid.org/Dienst/UI/1.0/Journal?authority=euclid.jdg

GET /Dienst/UI/1.0/Journal?authority=euclid.jdg HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://projecteuclid.org/jdg
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Safari/419.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Host: projecteuclid.org

4. Web server returns response:

HTTP/1.1 200 OK
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Date: Mon, 15 Jan 2007 00:31:54 GMT
Content-Type: text/html; charset=utf-8

5. User requests /jdg in Safari again:  http://projecteuclid.org/jdg

GET /jdg HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Safari/419.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Host: projecteuclid.org

6. Web server returns response:

HTTP/1.1 200 OK
Date: Mon, 15 Jan 2007 00:31:58 GMT
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Last-Modified: Fri, 01 Oct 2004 16:17:43 GMT
ETag: "12d85a-214-415d8327"
Accept-Ranges: bytes
Content-Length: 532
Keep-Alive: timeout=5, max=89
Connection: Keep-Alive
Content-Type: text/html

7. JavaScript in response causes Safari to load: http://projecteuclid.org/Dienst/UI/1.0/Journal?authority=euclid.jdg

GET /Dienst/UI/1.0/Journal?authority=euclid.jdg HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://projecteuclid.org/jdg
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Safari/419.3
If-Modified-Since: Mon, 15 Jan 2007 00:31:54 GMT
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Connection: keep-alive
Host: projecteuclid.org

8. Web server returns response:

HTTP/1.1 304
Date: Mon, 15 Jan 2007 00:31:58 GMT
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Keep-Alive: timeout=5, max=88
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

Connection: Keep-Alive, Keep-Alive
Keep-Alive: timeout=5, max=87


Note two problems here:

1. The Content-Type is set to text/plain instead of text/html.
2. The Content-Type line has a blank line after it (two sets of \r\n characters), which makes the last two lines a part of the body of the response instead of the header.

I have no idea what's causing this, other than some bad server-side code.  (Since it happens on more than one web site, I'm going to have to guess that it's some open-source code that is behaving consistently incorrectly on whatever site it's installed on.)

I'm also not sure whether Safari should "try harder" to get the content type right", or to use its original cached MIME type (text/html) versus the MIME type given by the 304 response (text/plain).

One other interesting thing is that neither Firefox 2.0.0.1 nor Opera 9.10 exhibit this behavior, although OmniWeb 5.5.2 does.

[David Kilzer (:ddkilzer)]

A much shorter way to reproduce the issue (sending If-Modified-Since header with request):

$ telnet projecteuclid.org 80
Trying 128.84.158.74...
Connected to projecteuclid.org.
Escape character is '^]'.
GET /Dienst/UI/1.0/Journal?authority=euclid.annm HTTP/1.1
Host: projecteuclid.org
If-Modified-Since: Mon, 15 Jan 2007 01:35:16 GMT
Connection: close

HTTP/1.1 304
Date: Mon, 15 Jan 2007 01:41:35 GMT
Server: Apache/1.3.31 (Unix) mod_perl/1.29
Connection: close
Content-Type: text/plain; charset=ISO-8859-1

Connection: close

Connection closed by foreign host.

--

Why is WebKit caching this page?  It has a question mark in the URL, which commonly means it's a CGI script and shouldn't be cached.  Perhaps it's the use of location.replace() that's causing it to be cached?

This seems to be the root of the problem since other browsers don't appear to cache this document, or they at least don't send an If-Modified-Since header when requesting the document a second time.

[David Kilzer (:ddkilzer)]

After talking to Maciej on IRC, it seems that the Foundation classes (like NSURLRequest) are actually doing the caching of this URL and then adding the If-Modified-Since header on the subsequent requests which causes the server to send a broken 304 response.  I will file a Radar bug for the Foundation caching issue.

In the meantime, it may be prudent to evangelize the projecteuclid.org web site administrator to fix the 304 response for their pages.

[David Kilzer (:ddkilzer)]

Filed Radar bug:

<rdar://problem/4923955>
WebKit sends If-Modified-Since header for URL that other browsers do not (7396)

I'm going to leave this bug open and change the Component to Evangelism until the projecteuclid.org site is fixed.  It seems the original web site (consonancemusic.com) has already been fixed.

[David Kilzer (:ddkilzer)]

Created attachment 12437 [details]
Original source of projecteuclid.org/jdg

[David Kilzer (:ddkilzer)]

Created attachment 12438 [details]
Original source of projecteuclid.org/Dienst/UI/1.0/Journal?authority=euclid.jdg

[Alexey Proskuryakov]

(In reply to comment #21)
> Why is WebKit caching this page?  It has a question mark in the URL, which
> commonly means it's a CGI script and shouldn't be cached.

FWIW, I couldn't find anything to this effect in the RFC (the only thing special to query URLs seems to be that the cache shouldn't ever treat those as fresh, section 13.9).

Respecting the Content-Type of a 304 response sounds like a bug to me. 

[David Kilzer (:ddkilzer)]

(In reply to comment #26)
> Respecting the Content-Type of a 304 response sounds like a bug to me. 

Added note to Radar bug about this as well.  I don't see where WebKit does any 304 http status handling.

[David Kilzer (:ddkilzer)]

See also Bug 12341 Comment #19.

[David Kilzer (:ddkilzer)]

Note that this issue has been resolved for Safari in a recent Leopard build.

Closing this bug as RESOLVED/INVALID since it is not a WebKit bug, and since it's no longer necessary for the web site administrator to fix the 304 HTTP response.