使用Safari和Apache 2.2.3获取Javascript /图像资源时,为什么有些页面请求会挂起？

Question

我们的Ruby on Rails应用程序的一些用户抱怨说,页面请求偶尔会在Safari下无限期挂起(一对夫妇在Firefox下注意到它,但它绝大多数都是Safari用户).经过一些调查后,我们的Rails应用程序似乎正确地提供了这些请求,并且在获取HTML中引用的图像资源(托管在同一服务器上)时发生挂起.

我们已将Apache配置为直接为图像资源提供服务,并绕过Rails应用程序以提高性能.我们还在text/javascript/css资产上启用了gzip压缩.以下是我们的Apache虚拟主机配置中的相关设置 - 也许我们已经以这样的方式配置了这可以解释这些任意挂起请求？

RewriteEngine On

# Correct behaviour of IE under SSL
SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

SSLEngine On
SSLCertificateFile /etc/httpd/conf/ssl/_.mycert.com.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl/_. mycert.com.key
SSLCertificateChainFile /etc/httpd/conf/ssl/gd_bundle.crt

RequestHeader set X_ORIGINAL_PROTOCOL 'https'
RequestHeader set X_FORWARDED_PROTO 'https'

# Rewrite index to check for static
RewriteRule ^/$ /index.html [QSA] 
RewriteRule "^/(images|stylesheets|javascripts|system)/?(.*)" "$0" [L]

# Rewrite to check for Rails cached page
RewriteRule ^([^.]+)$ $1.html [QSA]

# Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

ExpiresActive On
<FilesMatch "\.(ico|gif|jpe?g|png|js|css)$">
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</FilesMatch>

以前有没有人遇到过类似的问题？

我们的Ruby on Rails Web应用程序在RedHat Enterprise Linux 5上使用mod_rails和Apache 2.2.3运行.

更新: 我现在尝试删除以下块,问题仍然存在,所以我们可以将expires头排除在问题之外:

ExpiresActive On
<FilesMatch "\.(ico|gif|jpe?g|png|js|css)$">
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</FilesMatch>

Answer 1

今天我在我们的网站上调试了一个类似的问题，度过了一段非常愉快的时光。Safari 用户（但似乎只有 Mac 上的用户）会抱怨我们的网站在加载页面时会随机“挂起”。它通常看起来挂在一个图像上 - 3 个项目中的 2 个已完成，等等 - 但后来我禁用了 Safari、JavaScript 和 CSS 中的缓存，你猜怎么着？页面仍然挂着。

首先，关于 Safari 缓存的说明。即使您在“开发”菜单中选择了“禁用缓存”并从“Safari”菜单中选择了“清空缓存”，您仍然拥有基于 RAM 的缓存。这意味着，如果您确实想要模拟空缓存，则必须在每次请求时退出 Safari，或者在按下“重新加载”按钮的同时按住 Option + Shift + Prayer-To-Deity-of-Choice 键。这花了我一段时间才弄清楚，在我弄清楚之前，我很难持续重现这个问题。

所以！没有 JavaScript、CSS 或图像，你还剩下什么？除了实际的 HTML 之外，没有太多内容。这让我意识到这可能与压缩有关。果然，在 IIS 6.0 中关闭压缩会导致页面立即加载。由于 IIS 6.0 没有基于用户代理关闭压缩的便捷方法，因此我使用IIRF（重写 URL 的 ISAPI 过滤器）来重写Accept-Encoding来自 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

问题似乎是，如果 Safari 正在接收静态压缩内容（即服务器发送标Content-Length头），则 Safari 会很好地处理它。但是，如果 Safari 正在接收动态压缩内容（即，服务器正在提供由 ASP.NET 呈现的响应，并且内容长度在完成之前未知，因此服务器发送Transfer-Encoding: chunked），则 Safari 会进入 Flaky Sir-Hangs-A -批次模式。

为什么？我不知道。但这就是我解决这个问题的方法。