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

前端 未结 5 2180
深忆病人
深忆病人 2021-02-10 07:56

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

5条回答
  •  挽巷
    挽巷 (楼主)
    2021-02-10 08:21

    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.

提交回复
热议问题