Bug 27507 – Resources loaded from the Highwinds CDN sporadically stall for 30 seconds

• Status: RESOLVED
• Resolution: INVALID
• Component: Page Loading

[David Baxter]

Created attachment 33189 [details]
Test Page

Sometimes, resources loaded from the Highwinds CDN seem to stall when loading. My test case uses images, but I have also noticed this issue with Flash .swf's.

This bug occurs sporadically, and generally not on the first load. For instance, the first load of the image_test.html file I have attached will usually result in all 14 images loading quickly and successfully. Sometimes, a refresh of the page will cause none of the images to appear for about 30 seconds, as if Safari/WebKit is waiting for something to timeout, and after 30 seconds, the images seem to snap right in (although they'll sometimes do this in sets of 4's). On other reloads, things load just fine.

Some browser sessions won't exhibit this problem at all, and others will have this problem 50-70% of the time.

I'm able to replicate this problem fairly frequently on the following setups:
- MacBook Pro, OS X 10.5.7, with Safari 4.0.2 (5530.19), as well as WebKit nightlies (r46126 as of right now)
- Mac Pro, OS X 10.4.11, with Safari 4.0 (4530)
- MacBook, OS X 10.5.7, with Safari 4.0

I can not get this problem to occur on older versions of Safari, such as 3.2.3 (5525.28.3) running on OS X 10.5.7 (I've tried on 2 different machines that haven't upgraded to Safari 4 yet). I also don't remember it occurring on the Safari 4 public betas. Other browsers, like Firefox, don't exhibit any of these problems. This problem seems to be limited to content that is delivered through the Highwinds CDN, viewed through Safari.

[David Baxter]

Created attachment 33190 [details]
WebKit's Web Inspector showing the delayed loading times

[Mark Rowe (bdash)]

Thanks for the bug report.  The following two commands demonstrate the issue:

mrowe@daisy:~$ curl -I "http://cds019.sj1.hwcdn.net:80/k8q5c4b4/cds/talbot/dmin/anthony_t.jpg?doppl=4cf89cb4069e8a81&dopsig=3b2115527be4fc4792f97778fb52cfe9"
HTTP/1.1 200 OK
Date: Tue, 21 Jul 2009 19:20:03 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Accept-Ranges: bytes
ETag: "1241034776"
Last-Modified: Wed, 29 Apr 2009 19:52:56 GMT
Cache-Control: max-age=0
Server: Powered by Highwinds-Software
Content-Length: 35162
Content-Type: image/jpeg

mrowe@daisy:~$ curl -H 'If-None-Match: "1241034776"'  -I "http://cds019.sj1.hwcdn.net:80/k8q5c4b4/cds/talbot/dmin/anthony_t.jpg?doppl=4cf89cb4069e8a81&dopsig=3b2115527be4fc4792f97778fb52cfe9"
HTTP/1.1 304 Not Modified
Date: Tue, 21 Jul 2009 19:20:04 GMT
Accept-Ranges: bytes
ETag: "1241034776"
Server: Powered by Highwinds-Software
Content-Length: 35162
Content-Type: image/jpeg

mrowe@daisy:~$ 

In particular, the problem here is the Content-Length header that is present in the 304 response.  This leads to CFNetwork waiting for the body of the HTTP response to be delivered, which never happens.  The connection eventually times out and is closed, at which point the cached image is displayed.  The HTTP specification says that "All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body".  The presence of a Content-Length header typically indicates that a message body follows, so it seems that the server isn't following the HTTP specification correctly here.

[Mark Rowe (bdash)]

To summarize, there are two issues here:
1) The server is sending a Content-Length header that it shouldn't be.  If it did not send this header then all would be well.
2) CFNetwork gets confused by the Content-Length header and tries to read data that did not arrive.  If it ignored the Content-Length header on 304 responses then all would be well.

Since both of the issues are outside of the control of WebKit, there's nothing WebKit itself can do to address this problem.  I will migrate this bug in to Radar to track a CFNetwork fix for the second issue.  If you have any technical contacts at company hosting the content I would suggest pointing them at this bug report and having them address the first issue.

[Mark Rowe (bdash)]

<rdar://problem/7079316>

[Mark Rowe (bdash)]

Thanks again for the bug report.  This bug will be closed as INVALID to indicate that the problem is outside of WebKit.  CFNetwork folks will investigate the problem via the internal bug report that I indicated above.