HTTPヘッダーの拒否とnnCoection

Question

Web上の相互運用性に関しては、しばしばいくつかの問題があります。ブラウザベンダーにとってのこれらの問題の1つは、間違って綴られたConnection HTTPヘッダーです。最も一般的なエラーは、これらの2つの形式によって与えられます。

nnCoection: 
Cneonction: 

Fun with HTTP headersを含むこれに関する記事がいくつかあります。時にはそれは時代によって起こっていて消えてしまいます。 this example：NetScalerアプライアンスなどのロードバランサによって作成されたものもあります。

これらの問題を引き起こすハードウェアまたはソフトウェアの他のインスタンスを知っていますか？

更新ここでは、良いConnection HTTPヘッダーを返信しないサイトの例を示します。 AWSについてアマゾンのフォーラムで

curl -sI ehg-nokiafin.hitbox.com 
HTTP/1.1 200 OK 
Date: Tue, 25 Jan 2011 20:35:45 GMT 
Server: Hitbox Gateway 9.3.6-rc1 
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP LAW NID PSA ADM OUR IND NAV COM" 
Cneonction: close 
Pragma: no-cache 
Cache-Control: max-age=0, private, proxy-revalidate 
Expires: Tue, 25 Jan 2011 20:35:46 GMT 
Content-Type: text/plain 
Content-Length: 23 

更新2011-01-26

、nnCoectionについてthreadがあります。コメントは述べています：FYI

、それはインターネット チェックサム（単純合算）はまだ を加算するように 接続がある単語をmisspells理由、変更は パケットレベルで発生する可能性があります。この方法。完全に がヘッダーを削除した場合は、 が応答を停止し、ヘッダーが完全に読み取られるまで まで応答を停止する必要があるため、 はヘッダーを書き換えて、 チェックサムを再計算してから送信することができます。

sum(ord(c) for c in "Connection") 

と

sum(ord(c) for c in "nnCoection") 

と

の両方が1040

Answer 1

を与えるあなたはそれが実際の問題のですか？リンクされた記事は、ロードバランサ、リバースプロキシ、または他のミドルボックスが、接続上にTCPストリームの位置のデルタを追跡することなく、接続が維持されるというサーバーの望みを敗北させるように、これらの種類のヘッダーが「誤ってスペルミス」していることを示唆しています。接続の寿命。このようなことは、オンラインにされたサーバーに移行するために他のサーバーへの接続を強制的に維持することによって、ダウンして回復したサーバーを現役に戻す必要があるかもしれません。

HTTP Connection: keep-alive（cough）に依存するプロトコルをお持ちの場合は、間違っている可能性があります。