Why do some page requests hang when fetching Javascript/image assets using Safari and Apache 2.2.3?

Question

Some of the users of our Ruby on Rails app have complained that page requests occasionally hang indefinitely under Safari (a couple have noticed it under Firefox, but it\'s over

Answer 1

Olly,

This may or may not be related, but browsers have a limit of 2 (by default) simultaneous connections that they can make. If there are connections kept open for communication, and you are also fetching images, the call to the image may not go through till the browser has one of its stipulated connections free. The hang during image fetch may actually be triggered by some other server connections which are not completing or are being held open by the server and browser. So you may actually be hunting in the wrong place.

If you are able to reproduce the error, try switching to HTTP 1.0 on your dev server and see if it fixes the issue. Also try moving some of the assets to another domain/subdomain and fetch from there.

Hope that gives you another angle.

Regards, Narayan

Answer 2

Same problem in a Oaracle ias 10.1.3.4 server browsing with Safari 5.1 in Windows.

The problem disappear if the keepalive negotiation is disabled for Safari browser (httpd.conf):

BrowserMatch "Safari" nokeepalive

I'm not sure what the real problem is, or if the previous solutions is the best, but this configuration fix the problem.

Answer 3

I know this is an old topic, but I wanted to share a solution for Safari that might save others some time. The following line really solved all problems:

BrowserMatch "^(?=.*Safari)(?=.*Macintosh)(?!.*Chrom).*" nokeepalive gzip-only-text/html

The regex makes sure only Safari on Mac is detected, and not Mobile Safari and Chrome(ium) and such. Safari for Windows is also not matched, but the keepalive problem seems to be a Mac-Safari combination only. In addition, some Safari versions do not handle gzipped css/js well.

All our symptoms of our site crashing or CSS not completley loading in different versions of Safari which caused me to nearly pull my hair out (Safari really is the new IE) have been solved for us with this Apache 'configuration hack'.

Answer 4

Some things that might help, in no particular order:

1. Use asset hosts, they are extremely easy to setup: http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html
2. Make sure that Javascript is loaded near the bottom of the page, when possible.
3. Make sure that Apache/Nginx/whatever correctly sets the Expires-In HTTP header.
4. Run Google Speed Page under Firefox, this will provide lots of good info.

Answer 5

I was having a spectacularly good time debugging a similar issue on our site today. Safari users--but seemingly only those on a Mac--would complain that our site would "hang" randomly while loading a page. It usually appeared to be hanging on an image--2 of 3 items completed, etc.--but then I disabled the cache in Safari, JavaScript, and CSS, and guess what? The page still hung.

First, a note on Safari caching. Even if you have "Disable Caching" selected in the "Develop" menu and have selected "Empty Cache" from the "Safari" menu, you still have a RAM-based cache. This means that if you REALLY want to simulate an empty cache, you have to quit Safari with each request or hold down the Option + Shift + Prayer-To-Deity-of-Choice keys while pressing the Reload button. This took me a while to figure out, and until I figured it out, I had a hard time consistently reproducing the issue.

So! Without JavaScript, CSS, or images, what do you have left? Not much, aside from the actual HTML. This is what turned me onto the fact that is was probably compression related. And sure enough, turning off compression in IIS 6.0 resulted in the page loading instantaneously. Since IIS 6.0 doesn't have a convenient way of turning off compression based on the user agent, I used IIRF (an ISAPI filter that rewrites URLs) to rewrite the Accept-Encoding header when it comes from Safari:

# Safari doesn't handle gzip compression properly; we turn it off by setting 
# the q value to zero for all agents identifying themselves as Safari
RewriteCond %{HTTP_USER_AGENT} Safari
RewriteHeader Accept-Encoding: .* *;q=0

The issue seems to be that if Safari is receiving static compressed content (that is, the server sends the Content-Length header), then Safari deals with it just fine. But if Safari is receiving dynamic compressed content (that is, the server is serving a response being rendered by ASP.NET and the content length is not known until it's done, so the server sends Transfer-Encoding: chunked) then Safari goes into Flaky Sir-Hangs-A-Lot Mode.

Why? I have no idea. But this is how I work around it.