5/20の記事の続きです。
このバグの対策を行うためには、Internet Explorerの詳細設定を変更することが必要だと分かりました。
お次は副作用について検討してみましょう。 このバグの対策により、他のWinINetを使用しているほぼ全てのアプリケーションがHTTP 1.1からHTTP 1.0へ移行することになるわけです。さて、どんな不具合が発生する可能性があるでしょうか。
これはさすがに分かりません。世の中WinINet使っているアプリケーションは山ほどありますし、HTTPサーバも山ほどありますので、全部検討するのはどうみても無理です。
そこで肝心のHeimdallrに悪影響がないことだけでも確認しておくことにしました。 でもHeimdallrの挙動はサーバ側の動作によって変わるので、ある程度サーバを絞り込む必要があります。 今回は、Feed Meterのブログランキングを利用してサーバを絞り込み、確認OK判断を次のように行うことにしました。
Feed Meterのブログランキング100位までに登録されているRSS FeedのURLを全てHeimdallrに登録し、HTTP 1.0とHTTP 1.1でHTTPリクエスト送信の際のリクエストヘッダとレスポンスヘッダを 取得し、HTTPバージョンの違いによるヘッダの差異を目視確認して、問題なければOKとする。
HTTP 1.0のリクエストはこうでした。
GET /xxx.rdf HTTP/1.0 User-Agent: Heimdallr 1.11alpha2 Accept-Encoding: gzip Host: www.example.com Pragma: no-cache
HTTP 1.1のリクエストはこうでした。
GET /xxx.rdf HTTP/1.1 User-Agent: Heimdallr 1.11alpha2 Accept-Encoding: gzip Host: www.example.com Cache-Control: no-cache
キャッシュに関するフィールドがあるのは、HttpOpenRequestのフラグにINTERNET_FLAG_RELOADを指定したからでしょう。
HostフィールドはWinINetが勝手に付与したフィールドです。このHostフィールドはHTTP 1.1じゃないと使えないと思うのですが、HTTP 1.0でも平気で使ってます。
また、Accept-Encodingフィールドも、HTTP 1.0では"x-gzip"の方が良さそうです。
肝心のレスポンスヘッダですが、結果としては問題はまったくありませんでした。
ステータスコードは全て一致していました。
フィールドの違いは若干ありましたが、意味のありそうな違いはありませんでした。
一応気が付いた点を列挙しておきます。
HTTP 1.0使用時にTransfer-Encodingフィールドを付けるサーバはありませんでした。これがあったらバグが再現してしまうので無くてなによりです。
HTTP 1.0使用時にConnection: closeを付けるサーバがありました。あまり意味はないと思うんですが・・・。
HTTP 1.0使用時にX-Pad: avoid browser bugを付けるサーバがありました。古いブラウザのバグ避け用であまり意味はないはずです。
HTTP 1.1使用時にAccept-Encoding: gzipを付けるサーバは、HTTP 1.0使用時でも付けていました。
結局具体的な問題はありませんでした。一番心配だったのはHTTP 1.0にはVirtualHost機能がないことだったのですが、HTTP 1.0でもWinINetは平気でHostフィールドを付けるし、サーバも平気でHostフィールドを処理するので問題がなさそうです。
なお、これは2006/05/17の時点でFeed Meterのブログランキングのトップ100に登録されているサーバについてだけのお話です。世の中でどれくらい通用するのかは分かりません。ですが、これを見た限りでは、HTTP 1.1の替わりにHTTP 1.0を使っても具体的な問題は無さそうです(仕様上の問題はたくさんありそうですが)。
ところで、この検討を行って感じたのですが、世の中のWebサーバ(今回確認したサーバは90%がApacheでしたが)は、あまりHTTPバージョンに拘らず、具体的な問題が発生しないよううまくHTTPリクエストを捌きますね。 きっと、過去、HTTPのバージョンが上がったときに発生した色々な互換性問題をクリアしていって今のような実装になったのでしょう。なんとなく歴史を感じました。
投稿者 MASATO : 2006年05月22日 23:34 | トラックバック