[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

クライアントでわかっている問題

時間が経つにつれて、Apache グループは次善策のある様々なクライアントの問題を発見し、発表しています。このドキュメントはこれらの問題と有効な次善策を記述しています。特別な順番に並んでいるわけではありません。スタンダードにいくらか精通していると仮定していますが、絶対的なものではありません。

簡潔にするために、Navigator は Netscape's Navigator の製品で、MSIE は Microsoft's Internet Explorer の製品とします。全ての商標と著作権はそれぞれの企業に帰属します。この記述にある矛盾を訂正するためか、壊れて/修復された正確なバージョンを私達に教えるために、様々なクライアントの作者からのインプットを歓迎します。

HTTP/1.0 を定義するRFC1945RFC2068 を定義する HTTP/1.1 を参照してください。version 1.2 の Apache は HTTP/1.1 サーバです(オプションの HTTP/1.0 プロキシーで)。

様々なこれらの次善策は環境変数が引き金となります。mod_browser を使うことによって通常、管理者は設定されたものをクライアントのために管理します。別のやり方がなければ、バージョン 1.2 とそれ以降では記述されたこれらの次善策が全て存在します。

POST での CRF をトレイリングする

これは以前からある発行版です。CERN ウェブサーバは、それに続く余分な CRLF を持つ POST データをリクエストします。このように多くのクライアントはリクエストの Content-Length に含まれない余分の CRLF を送信します。Apache はリクエストの前に現れる空行をなくすことで、この問題を解決します。

keepalive が壊れる

様々なクライアントが keepalive(持続的な接続) の実行を停止します。特に Navigator 2.0 のウィンドウズ版はサーバのアイドル接続のタイムアウト時に非常に混乱します。次善策はデフォルトのコンフィグファイルに存在します:

BrowserMatch Mozilla/2 nokeepalive
これはちょうど、Navigator のように user-agent ストリングでそれ自身 Mozilla を呼び出すことを始める MSIE の初期バージョンと一致していることに注意してください。

HTTP/1.1 をサポートすることを要求する MSIE 4.0b2 は、それが 301 か 302 (redirect) のレスポンスで使われると keepalive を適切にはサポートしません。不幸にも 1.2.2 より優先する Apache の nokeepalive コードは HTTP/1.1 では動きません。1.2.1 のバージョンに このパッチをあてなければなりません。それから、コンフィグにこれを追加してください:

BrowserMatch "MSIE 4\.0b2;" nokeepalive

レスポンスでの HTTP/1.1 の誤った解釈

RFC1945 のセクション 3.1 から引用:

HTTP はプロトコルのバージョンを示す一覧に番号を付ける "<MAJOR>.<MINOR>" を使います。プロトコルバージョンには、通信によって得られた特徴よりもむしろ、メッセージのフォーマットを示す送信側と、HTTP の通信をさらに理解するための容量を許可する傾向があります。
Apache は HTTP/1.1 サーバなのでそのような反応を一部示します。多くのクライアント使用者はレスポンスがプロトコルに存在することを示すようなこの部分のレスポンスを誤って扱い、それからレスポンスを受け入れることを拒絶します。

この問題の最初の主な兆候は、AOL のプロキシーサーバでした。Apache 1.2 がベータになったときは、最初の wide-spread HTTP/1.1 サーバでした。議論の後に AOL はそれらのプロキシーを修正しました。似たような問題を予測して、force-response-1.0 環境変数が Apache に追加されました。現在の Apache は HTTP/1.0 クライアントに対するレスポンスで、"HTTP/1.0"を示していますが、レスポンスを変える、なにか他の方法を示してはいません。

多くのクライアント (Navigator 3.x and MSIE 3.x を含む)で使われている pre-1.1 Java Development Kit (JDK) はこの問題を公開しています。1.1 JDK の初期プレリリースでいくつか行っているからです。1.1 JDK リリースで修正されると思います。次善策にはいくつかあります:

BrowserMatch Java/1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0

Progressive Networks からの RealPlayer 4.0 もまたこの問題を公開しています。しかし、彼等は player のバージョン 4.01 でそれを修正しましたが、バージョン 4.01 はバージョン 4.0 と同じ User-Agent を使っています。次善策はまだです:

BrowserMatch "RealPlayer 4.0" force-response-1.0

レスポンスが HTTP/1.0 になければならないのを除いて、リクエストが HTTP/1.1 を使う

MSIE 4.0b2 はこの問題を持っています。その Java VM は HTTP/1.1 フォーマットでリクエストを作りますが、レスポンスは HTTP/1.0 フォーマットでなければなりません(特に、chunked のレスポンスを認識しません)。次善策は、リクエストが HTTP/1.0 フォーマットに入ることを Apache に信じさせることです。

BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0
この次善策は 1.2.2 と パッチのある 1.2.1 で有効です。

ヘッダ解析の境界の問題

もしレスポンスヘッダの CRLF をトレイリングが、レスポンスの offset 256、257、258 で始まれば、2.0 から 4.0b2 (と可能な限り新しいもの) の全ての Navigator のバージョンは問題を持っています。これの BrowserMatch は、ほとんどあらゆるヒットでマッチしているので、次善策は全てのレスポンスで自動的に可能になります。その次善策は、この状態がレスポンスの中で生じて、レスポンスの offset 258 を通り過ぎた CRLF のトレイリングをプッシュするため、ヘッダに余分な割り当てを追加するときに検出することです。

様々な部分からなるレスポンスと引用された境界ストリング

様々な部分からなるレスポンスで、いくつかのクライアントは境界ストリングで引用の(")を受け入れません。MIME は標準でそのような引用が使われることを推奨しています。しかしクライアントは恐らく、引用を含んでいない RFC2068 での例の一つを基にして書かれています。Apache はこの問題の次善策に対して、その境界ストリングでは引用を含みません。

Byterange のリクエスト

byterange のリクエストは、クライアントがオブジェクトの部分を検索することを望んで、必ずしも完全なオブジェクトを検索することを望まないときに使われます。URL にあるこれらの byterange を含んだ非常に古い draft がありました。MAC の Navigator 2.0b1 と MSIE 3.0 のような古いクライアントはこの動きを示し、";xxx-yyy" のトレイリングに対する URL を検索するための(失敗した)試行のようなサーバのサクセスログに現れるでしょう。Apache はこれを全く実行しようとしません。

このスタンダードに続く draft はヘッダ Request-Range とレスポンスタイプ multipart/x-byteranges を定義します。HTTP/1.1 スタンダードは2、3の修正でこの draft を含み、ヘッダ Range と タイプ multipart/byteranges を定義します。

Navigator (バージョン 2 と 3)は RangeRequest-Range ヘッダ(同じ値で)の両方を送信しますが、multipart/byteranges レスポンスは受け入れません。レスポンスは multipart/x-byteranges でなければなりません。次善策としては、Apache が Request-Range ヘッダを受け取っていれば、それを Range ヘッダよりも"高い優先度があり"、レスポンスで multipart/x-byteranges を使うと解釈します。

Adobe Acrobat Reader のプラグインは byterange の使用を拡張して、multipart/x-byterange レスポンスだけをサポートするバージョン 3.01 より優先します。不幸にもプラグインがリクエストを作っている情報を与えてはいません。もしプラグインが Navigator で使われれば、上記の次善策はうまく働きます。しかし、もしプラグインが MSIE 3 (ウィンドウズ上) で使われていれば、次善策は働きません。なぜなら MSIE 3 は Navigator が行う Range-Request の情報を与えないからです。To workaround this, Apache special cases "MSIE 3" in the User-Agent and serves multipart/x-byteranges. MSIE 3 に対してこのために必要なものは、Acrobat プラグインのせいであって、ブラウザのせいではないことに注意してください。

Netscape Communicator は標準ではない Request-Range ヘッダを出さないように言っています。バージョン 3.01 に優先する Acrobat プラグインがそれに使われると、byterange を正しく認識しません。ユーザは Acrobat reader を 3.01 にアップグレードしなければなりません。

Set-Cookie ヘッダがマージできない

HTTP の設計明細書は複写した名前でヘッダを強制的に一つに(セミコロンで分けられている)マージすることを言っています。いくつかのブラウザはマージされたヘッダを好まないクッキーをサポートして、それぞれの Set-Cookie ヘッダが別々に送信されることを好みます。CGI によって返されたヘッダを解析すると、Apache はなんらかの Set-Cookie ヘッダをマージすることを明白に無効にします。

Expires ヘッダと GIF89A アニメーション

バージョン 2 から 4 を通じて、Navigator は、もし最初のレスポンスが Expires ヘッダを含んでいれば、アニメーションのそれぞれのループで誤って GIF89A アニメーションを再びリクエストするでしょう。これは終了時間がどのくらい先に設定されていようと関係なく発生します。Apache で供給されている次善策はありませんが、1.21.3 のための hacks があります。

Content-Length を持たない POST

間違いのない状況下で 3.01 から 3.03 にかけての Navigator は、リクエスト本体なしの POST の発行は不正確であるように見えます。知られている次善策はありません。Navigator 3.04 では修正されており、Netscape は いくつかの情報を用意しています。実際の問題についても情報があります。


Apache HTTP Server Version 1.3

検索文字
Index Home The English original manual is here.
このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。

JAPACHE ホームページ