Bug 11339 - Explanation of head vs. body timeout on dead hostnames
Summary: Explanation of head vs. body timeout on dead hostnames
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 419.x
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2006-10-17 22:36 PDT by Kurt Moore
Modified: 2022-06-23 19:49 PDT (History)
7 users (show)

See Also:


Attachments
Example safari stall file (408 bytes, text/html)
2006-10-19 17:55 PDT, Kurt Moore
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kurt Moore 2006-10-17 22:36:14 PDT
Any calls to external sites in the head portion of an html document, such as .js, .xml, .css etc can cause Safari to stall for exceedingly long periods of time.

In my tests, if a remote host is called, and that host is not reachable, eventually, "Activity" window in Safari will show a timeout, however, no page data will be loaded until that timeout occurs.  This timeout is exceedingly long, minutes perhaps.  NXDOMAIN, seems to gracefully fail immediately, this is only on hosts in which I can not traceroute or ping them.

Conversely, putting these calls into the body of the document, though not valid, will yield a instant "timed out" in the Safari "Activity" window.

This poses problems on sites, such as myspace.com, where they are constantly down on one of the many css or js servers they use.

While this does not seem to be limited to Safari, and all the browsers I test on OS X behave in this way, the timeout value in Safari seems exceedingly long.  Windows IE is at around 10 seconds.

Can I have some form of explanation of how this works, and if this setting is adjustable?  I understand site view results may not be as expected, however, most users suspect the entire site is down, when in almost all the cases I run into, `curl` in the command line, has no issues loading the html page, it is a external resource that is not working.  In those cases, a more sane timeout would at least allow me to read the content, and if I desire, refresh the page and try again to load the external resources.
Comment 1 Mark Rowe (bdash) 2006-10-18 01:10:59 PDT
Can you provide the URL of a page which does this reproducibly?  It's not particularly clear from your description what the issue you're describing is.  If we can see it in action it would be easier to analyze.
Comment 2 Alexey Proskuryakov 2006-10-18 04:27:05 PDT
I also do not fully understand the problem description, but I have a few questions:
- You said that no page data is loaded before timeout. Is it not loaded, or not displayed? What does Activity window say?
- Do you still see this problem with nightly builds from <http://nightly.webkit.org>?

Generally, people complain about the contrary - if a stylesheet is slow to load, unstyled content appears for a moment, causing a "flash of unstyled content."
Comment 3 Kurt Moore 2006-10-19 17:55:00 PDT
Created attachment 11160 [details]
Example safari stall file
Comment 4 Kurt Moore 2006-10-19 17:57:00 PDT
I will clarify and attach a file:

Basically, in the head I put this:
<script type="text/javascript" src="http://64.24.56.47/foo.js"></script>
now, that as far as I can tell, and I hope for as long as it needs to be for this test, is a dead IP, as in not http responds at it at this moment.  It could be a real IP, or hostname, just not responding due to load etc.

When I load the stall.html file, Activity shows me 0.4KB loaded, which is the html file itself, Safari shows me nothing, I do not see "this page stalls badly"

http://64.24.56.47/foo.js shows 0 bytes of ? for a total of:
1 minute and 15 seconds, and then I get 
http://64.24.56.47/foo.js timed out

After that, the rest of the page loads, and I see the body copy.

The problem also happens sometimes, with certain script calls inside the body as well.  

If you ask Mac users what they think of myspace, they will all say that it is always "down", whereas windows users do not seem to have the same sentiment.  While it is true, the .js servers do often go down, that does not prevent a windows user from loading the page for more than about 15 seconds, from there, they are ok to move on.  On the Mac, users more or less assume the site is dead, and will not wait over a minute to see it load.

Yes, the behavior is identical in the nightly, which I just tested in.
Comment 5 Kurt Moore 2006-10-19 17:59:19 PDT
I should note, since bugzilla actually shows my attachment, when you click on it, you will be waiting 1:15 just to get to the source of my sample attachment.
Comment 6 Mark Rowe (bdash) 2006-10-19 18:01:36 PDT
Thanks for the test case Kurt.
Comment 7 Kurt Moore 2006-10-26 00:56:10 PDT
Any idea on when I might see a response on this?  I think this is important because if you look through all the bugs reported in various forums, where myspace does not work etc, I have a feeling, it is as a result of this.  It is the one site that has so much going on (no, I do not even have an account), and despite my hatred for it, it shows why all Mac users complain that they can never load a myspace page, and all windows users say it works just fine.

Now i know better, even today, I hit two sites, that would not load, came to me from reddit.com, I watched the activity window, and sure enough, a dead .js host referenced in the head.  I used `curl` to fetch the article, and was able to at least read the text.
Comment 8 David Kilzer (:ddkilzer) 2007-04-17 22:02:48 PDT
I'm guessing the timeout value is probably in Foundation code, which is not part of WebKit (or even Safari).

Kurt, please file a bug on https://bugreport.apple.com/ and reference this bug.  (If you don't have an ADC account, you may create a free "online" ADC account on https://connect.apple.com/.)  When you've filed the radar bug, please post the bug number here and change the keyword from NeedsRadar to InRadar.

Comment 9 Mark Rowe (bdash) 2007-04-27 03:02:09 PDT
<rdar://problem/5166153>
Comment 10 Brady Eidson 2007-04-27 18:09:23 PDT
Note Firefox on Mac takes the same length of time as Safari to fail - this isn't Safari specific.
Comment 11 Kurt Moore 2007-04-27 18:17:52 PDT
Ahh, correct you are.  At least it resulted in getting reported to the correct channels.  Let's just hope that it gets worked out, I have a few outstanding issues in rdar, but they seem to take ages to get looked at.

Thanks again.
Comment 12 Kurt Moore 2007-04-27 18:18:12 PDT
Ahh, correct you are.  At least it resulted in getting reported to the correct channels.  Let's just hope that it gets worked out, I have a few outstanding issues in rdar, but they seem to take ages to get looked at.

Thanks again.
Comment 13 Ahmad Saleem 2022-06-23 13:00:49 PDT
It was concluded that this was not Webkit or Safari isolated issue in Comment 10 but rather something in Foundation code (OS issue - Comment 08) and as a result was happening in other browsers installed by the user as well (as in Comment 10). Can this be marked as "RESOLVED INVALID" or "RESOLVED WONTFIX"? Thanks!
Comment 14 Alexey Proskuryakov 2022-06-23 19:49:03 PDT
The Foundation issue is to make this timeout configurable, and we'd still need to adopt that in WebKit.

<rdar://problem/5166153> hasn't been resolved yet, but I don't know if this basic problem has been addressed in other ways. Certainly it's not a super common occurrence, and I don't remember personally observing such a behavior.