[Webkit-unassigned] [Bug 11339] New: Explanation of head vs. body timeout on dead hostnames

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=11339

           Summary: Explanation of head vs. body timeout on dead hostnames
           Product: WebKit
           Version: 419.x
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: kurt at formulateaffinity.com


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.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.