Safari works just fine. This is with nightly build WebKit-SVN-r18975.dmg
I can't reproduce, could you please check again?
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.
Marco e-mailed me a screenshot showing it, for which thx Marco :), but please follow ddkilzer's advice :)
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...
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.
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.
Another thing to consider is whether you're "behind" a proxy server that may be altering the original response from the web site.
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
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.
(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.
(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.
(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>
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 :-(
(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.
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.
(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.)
(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.
(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/ :-( >
(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. $
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!
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.
*** Bug 12548 has been marked as a duplicate of this bug. ***
Confirming per Bug 12548. I still want to perform the test in Comment #21.
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".