1

今朝、iPad（Safari Mobile / Webkit）を使用して構築しているWebアプリにアクセスしようとすると、非常に奇妙な問題が発生しました。フロントエンドでは、WebアプリはXHR/Ajaxリクエストに大きく依存しています。バックエンドでは、「Accept-Encoding」に「gzip」が含まれている場合、サーバーは応答をgzip圧縮するように構成されています。

サーバーをSSLに切り替えるまで、すべてがうまく機能していました。その後、Safariで断続的な「CFURLErrorDomain：303」エラーが発生し始めました。

簡単に検索した後、私はこのリンクを見つけました：

http://beyondrelational.com/modules/2/blogs/45/posts/12034/failed-to-load-resource-safari-issue.aspx

リンクによると、SafariはSSL / HTTPSを介してXHR（ajax）リクエストを行うときにcontent-lengthヘッダーを必要とします。私の場合、サーバーはコンテンツを出力ストリームに直接gzipしているので、最終的なコンテンツの長さを知る方法がありません。

回避策として、サーバーに次のロジックを追加しました。

    if (request.isEncrypted()) gzip =
        !request.getHeader("User-Agent").toLowerCase().contains("webkit");

つまり、接続がSSLを介して暗号化されており、ブラウザーがWebkitの派生物（Safari、Chromeなど）である場合は、出力を圧縮しないでください。これはうまくいくようですが、本当に遅くなります。

だから私の質問はこれです：

SafariはSSLを介したgzip圧縮応答をサポートしていますか、それとも間違ったツリーを吠えていますか？

4

1 に答える 1

1

私が見たエラーはサーバーのバグであり、Safariとは何の関係もありませんでした。サーバーは、大きなバイト配列を圧縮するときにチャンク転送エンコーディングに依存していました。個々の「チャンク」は断片（ヘッダー、本文、トレーラー）に分割され、別々のメッセージでクライアントに送信されました。SSLクライアント（safari）は、1つの連続した「チャンク」を予期していたため、不完全なチャンクを検出したときに何をすべきかわかりませんでした。サーバーにパッチが適用され、問題が解決されました。

于 2013-01-08T15:49:07.457 に答える