Bug 12341 – Shows the HTML / javascript "text" and does not render the page

• Component: Page Loading
• Status: RESOLVED INVALID

[Marco Papa]

Safari works just fine. This is with nightly build WebKit-SVN-r18975.dmg

[Joost de Valk (AlthA)]

I can't reproduce, could you please check again?

[David Kilzer (:ddkilzer)]

Marco, do you have any haxies or input managers (SafariStand, PithHelmet, Saft, etc.) installed?  If so, please retest without them installed.  Most of them will not work (cause crashing or strange behavior) with the WebKit nightly builds since the internal APIs have changed.

If you don't have them installed, we need specific instructions on how to reproduce the bug.

[Joost de Valk (AlthA)]

Marco e-mailed me a screenshot showing it, for which thx Marco :), but please follow ddkilzer's advice :)

[Joost de Valk (AlthA)]

Ok this is getting very weird... I've been able to reproduce it once now... Consequent reloads, with cache cleared and webkit restarted doesn't reproduce it at least once... we need some way to reproduce this if we're going to fix it...

[Marco Papa]

Created attachment 12601 [details]
shows the bug

An update. This URL works fine for me:

http://www.oreilly.com/catalog/html5/index.html

Removing the index.html, as in:

http://www.oreilly.com/catalog/html5/

shows the text instead. I have downloaded the latest build.

[David Kilzer (:ddkilzer)]

We need a list of steps to follow to reproduce this bug that work a reasonable percentage of the time.  Simply loading the URL has worked every time I've tried it.  See Bug 7396 Comment #18 for an example.

[David Kilzer (:ddkilzer)]

Another thing to consider is whether you're "behind" a proxy server that may be altering the original response from the web site.

[Mark Rowe (bdash)]

Being on a DSL connection with no explicit proxy server set does not preclude the presence of a proxy server.  Many ISPs employ "transparent" proxying as a means of reducing response times and data consumption.  I've taken a look at the HTTP headers that I receive from the two URLs in question and, as expected, they are identical.

It'd be great if you could post the HTTP headers that you're seeing from each of the URLs.  Taking these from outside of Safari would be one way to see if there is something external influencing the headers.  To do this, open up Terminal, run the following command, and paste the output into this bug report.

$ curl -s -i "http://www.oreilly.com/catalog/html5/" | head -n 20
and
$ curl -s -i "http://www.oreilly.com/catalog/html5/index.html" | head -n 20

[Mark Rowe (bdash)]

Marco, can I also ask that rather than replying to the emails you receive about changes on this bug that you add your comments into the bug itself?  This will ensure that your comments are recorded and available to anyone looking into this issue.

[Marco Papa]

(In reply to comment #7)
> Another thing to consider is whether you're "behind" a proxy server that may be
> altering the original response from the web site.
> 

I am not behind a proxy server. Just connecting though my home DSL line at verizon.

[Marco Papa]

(In reply to comment #8)
> [...]
> 
> It'd be great if you could post the HTTP headers that you're seeing from each
> of the URLs.  Taking these from outside of Safari would be one way to see if
> there is something external influencing the headers.  To do this, open up
> Terminal, run the following command, and paste the output into this bug report.
> 
> $ curl -s -i "http://www.oreilly.com/catalog/html5/" | head -n 20
> and
> $ curl -s -i "http://www.oreilly.com/catalog/html5/index.html" | head -n 20
> 

Sure. When I get home to my Mac tonight I will do that.

[Marco Papa]

(In reply to comment #8)
> Being on a DSL connection with no explicit proxy server set does not preclude
> the presence of a proxy server.  Many ISPs employ "transparent" proxying as a
> means of reducing response times and data consumption.  I've taken a look at
> the HTTP headers that I receive from the two URLs in question and, as expected,
> they are identical.
> 
> It'd be great if you could post the HTTP headers that you're seeing from each
> of the URLs.  Taking these from outside of Safari would be one way to see if
> there is something external influencing the headers.  To do this, open up
> Terminal, run the following command, and paste the output into this bug report.
> 
> $ curl -s -i "http://www.oreilly.com/catalog/html5/" | head -n 20
> and
> $ curl -s -i "http://www.oreilly.com/catalog/html5/index.html" | head -n 20
> 

Both of the calls above return the same IDENTICAL header:

HTTP/1.1 200 OK
Date: Tue, 23 Jan 2007 03:39:13 GMT
Server: Apache
P3P: policyref="http://www.oreillynet.com/w3c/p3p.xml",CP="CAO DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONo OUR DELa PUBi OTRa IND PHY ONL UNI PUR COM NAV INT DEM CNT STA PRE"
Last-Modified: Thu, 18 Jan 2007 21:01:24 GMT
ETag: "6cdf2f-a950-45afe024"
Accept-Ranges: bytes
Content-Length: 43344
Content-Type: text/html
X-Cache: MISS from www.oreilly.com

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

<title>oreilly.com -- Online Catalog: HTML & XHTML: The Definitive Guide, Fifth Edition</title>

[Mark Rowe (bdash)]

Ok, that header matches what I see while doing the same requests.

Marco, is it still reoccurring 100% of the time when you load <http://www.oreilly.com/catalog/html5/>, but not when you load <http://www.oreilly.com/catalog/html5/index.html>?  I have not been able to reproduce it at all, which suggests either I am doing something different than you are, that something differs in our environment which is influencing this, or the cause is in some way due to chance :-(

[Marco Papa]

(In reply to comment #13)
> Ok, that header matches what I see while doing the same requests.
> 
> Marco, is it still reoccurring 100% of the time when you load
> <http://www.oreilly.com/catalog/html5/>, but not when you load
> <http://www.oreilly.com/catalog/html5/index.html>?  I have not been able to
> reproduce it at all, which suggests either I am doing something different than
> you are, that something differs in our environment which is influencing this,
> or the cause is in some way due to chance :-(
> 

Yes, 100% of the time.

[Mark Rowe (bdash)]

Do you know how to use tcpdump?  If you do, it'd be great to get a packet dump of you loading each of the pages to determine if the same content is being retrieved by Safari in both cases.

[David Kilzer (:ddkilzer)]

(In reply to comment #14)
> Yes, 100% of the time.

At the risk of never reproducing it again, have you tried emptying your browser cache using Cmd-Alt-E?

(You may want to zip up and save a copy of ~/Library/Caches/Safari/ before you clear it just in case it's possible to reproduce using it.)

[Marco Papa]

(In reply to comment #15)
> Do you know how to use tcpdump?  If you do, it'd be great to get a packet dump
> of you loading each of the pages to determine if the same content is being
> retrieved by Safari in both cases.
> 

Actually, no, I haven't set up or use tcpdump. But I use ethereal instead.

[Marco Papa]

(In reply to comment #16)
> (In reply to comment #14)
> > Yes, 100% of the time.
> 
> At the risk of never reproducing it again, have you tried emptying your browser
> cache using Cmd-Alt-E?
> 
> (You may want to zip up and save a copy of ~/Library/Caches/Safari/ before you
> clear it just in case it's possible to reproduce using it.)

Ha, too late. I cleared the cache and now the bug doesn't happen any more. Unfortunately I didn't save a copy of ~/Library/Caches/Safari/ :-(
> 

[David Kilzer (:ddkilzer)]

(In reply to comment #18)
> Ha, too late. I cleared the cache and now the bug doesn't happen any more.
> Unfortunately I didn't save a copy of ~/Library/Caches/Safari/ :-(

Very interesting.  This looks a lot like Bug 7396 Comment #21 where a Content-Type of text/plain is returned with a 304 http status:

$ telnet www.oreilly.com 80
Trying 208.201.239.36...
Connected to www.oreilly.com.
Escape character is '^]'.
GET /catalog/html5/ HTTP/1.1
Host: www.oreilly.com
Connection: close
If-Modified-Since: Tue, 23 Jan 2007 11:32:51 GMT

HTTP/1.1 304 Not Modified
Date: Tue, 23 Jan 2007 11:33:55 GMT
Server: Apache
ETag: "6cdf2f-a950-45afe024"
X-Cache: MISS from www.oreilly.com
Connection: close
Content-Type: text/plain

Connection closed by foreign host.
$ 

[David Kilzer (:ddkilzer)]

Since Marco was the only person who was able to reproduce this bug (and now can't after clearing his browser cache), I'm going to close this bug as RESOLVED/WORKSFORME.

Marco, if you see a problem with this page again, please reopen this bug, or open a new bug for another page that displays as source.  Thanks!

[David Kilzer (:ddkilzer)]

I just thought of an interesting "torture test" for WebKit:

1. Load a static HTML page with a "bad" mime type of text/plain so that it's cached.
2. Fix the web server to send the correct mime type of text/html.
3. Will Safari (or any other browser, for that matter) notice the difference?

This scenario is possible if a web server were configured incorrectly, someone browsed to a page, then the server configuration was fixed (without the content being updated).  I think.

[David Kilzer (:ddkilzer)]

*** Bug 12548 has been marked as a duplicate of this bug. ***

[David Kilzer (:ddkilzer)]

Confirming per Bug 12548.  I still want to perform the test in Comment #21.

[Ahmad Saleem]

It was confirmed by the bug reporter that cleaning cache and cookies fixed the issue in Comment 18 and in Comment 21, David mentioned that he want to have tests to cover the following bug. I think WPT do have coverage of invalid mime type so we can mark this as "RESOLVED INVALID" for time being, if I am wrong, please ignore my comment and reopen or mark it as "RESOLVED LATER".