Bug 12341 - Shows the HTML / javascript "text" and does not render the page
Summary: Shows the HTML / javascript "text" and does not render the page
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 420+
Hardware: Mac (PowerPC) OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.oreilly.com/catalog/html5/
Keywords:
: 12548 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-01-20 00:26 PST by Marco Papa
Modified: 2022-08-08 16:00 PDT (History)
9 users (show)

See Also:


Attachments
shows the bug (168.48 KB, image/png)
2007-01-22 00:52 PST, Marco Papa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Papa 2007-01-20 00:26:26 PST
Safari works just fine. This is with nightly build WebKit-SVN-r18975.dmg
Comment 1 Joost de Valk (AlthA) 2007-01-20 01:50:40 PST
I can't reproduce, could you please check again?
Comment 2 David Kilzer (:ddkilzer) 2007-01-20 04:33:11 PST
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.

Comment 3 Joost de Valk (AlthA) 2007-01-20 04:44:28 PST
Marco e-mailed me a screenshot showing it, for which thx Marco :), but please follow ddkilzer's advice :)
Comment 4 Joost de Valk (AlthA) 2007-01-22 00:22:58 PST
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...
Comment 5 Marco Papa 2007-01-22 00:52:07 PST
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.
Comment 6 David Kilzer (:ddkilzer) 2007-01-22 04:41:10 PST
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.

Comment 7 David Kilzer (:ddkilzer) 2007-01-22 15:09:24 PST
Another thing to consider is whether you're "behind" a proxy server that may be altering the original response from the web site.

Comment 8 Mark Rowe (bdash) 2007-01-22 15:39:48 PST
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
Comment 9 Mark Rowe (bdash) 2007-01-22 15:40:55 PST
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.
Comment 10 Marco Papa 2007-01-22 16:25:10 PST
(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.
Comment 11 Marco Papa 2007-01-22 16:26:49 PST
(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.
Comment 12 Marco Papa 2007-01-22 19:52:41 PST
(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>
Comment 13 Mark Rowe (bdash) 2007-01-22 20:01:44 PST
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 :-(
Comment 14 Marco Papa 2007-01-22 20:13:47 PST
(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.
Comment 15 Mark Rowe (bdash) 2007-01-22 20:31:32 PST
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.
Comment 16 David Kilzer (:ddkilzer) 2007-01-22 20:43:57 PST
(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.)

Comment 17 Marco Papa 2007-01-22 21:59:09 PST
(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.
Comment 18 Marco Papa 2007-01-22 22:05:00 PST
(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/ :-(
> 

Comment 19 David Kilzer (:ddkilzer) 2007-01-23 03:51:32 PST
(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.
$ 

Comment 20 David Kilzer (:ddkilzer) 2007-01-29 04:49:31 PST
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!

Comment 21 David Kilzer (:ddkilzer) 2007-01-29 05:34:06 PST
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.

Comment 22 David Kilzer (:ddkilzer) 2007-02-04 01:16:01 PST
*** Bug 12548 has been marked as a duplicate of this bug. ***
Comment 23 David Kilzer (:ddkilzer) 2007-02-07 07:33:41 PST
Confirming per Bug 12548.  I still want to perform the test in Comment #21.
Comment 24 Ahmad Saleem 2022-08-08 15:59:58 PDT
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".