問題タブ [http-1.0]

HTTP 1.0 と HTTP 1.1 の違いを簡単に説明してくれませんか? 私は両方の RFC にしばらく時間を費やしましたが、それらの間の多くの違いを引き出すことができませんでした。ウィキペディアは次のように述べています。

HTTP/1.1 (1997-1999)

現行版; 永続的な接続はデフォルトで有効になっており、プロキシとうまく連携します。リクエストのパイプラインもサポートしているため、複数のリクエストを同時に送信できるため、サーバーはワークロードに備えて、リクエストされたリソースをより迅速にクライアントに転送できる可能性があります。

しかし、それは私にとってあまり意味がありません。これはやや複雑なテーマであることは承知しているため、完全な回答は期待できませんが、もう少し低いレベルでの違いの簡単な概要を教えてもらえますか?
つまり、HTTP サーバーまたはアプリケーションを実装するために知っておく必要がある情報を探しているということです。私は主に正しい方向へのナッジを探しているので、自分でそれを理解することができます.

Apacheで実行されているPHPスクリプトで、HTTPリクエストがHTTP/1.0リクエストであるかHTTP/1.1リクエストであるかを判断する必要があります。この情報を照会する方法はありますか？

Web サービスと通信するための基本的な http クライアントを実装していますが、http 1.0 と 1.1 のどちらを使用するべきか迷っています。データ セクションはバイナリ データで構成され、リモート サーバーは常に私 (IIS7.5 を実行) によって制御されます。間にあるファイアウォール/プロキシは、私が制御しているものではありません。間違った http バージョンが使用されている場合、パケットを停止してはなりません。

http 1.0 と 1.1の違いについて調べてみたところ、http 1.0 は必要なものすべてをサポートしているように思えます。

1.1 ではなく http 1.0 を選択した場合、問題が発生しますか? それとも、すべてが正常に機能すると仮定できますか?

raw ソケット経由で IIS7.5 に接続し、http 1.0 の get 要求を送信すると、応答は常に http 1.1 になるのが不思議です。

「HTTP：The Definitive Guide」によると、

HTTP / 1.1では接続がデフォルトで永続的であり、送信して手動で閉じる必要があると指定されているため、永続的な接続を指定することはHTTP/1.1では非推奨です。

したがって、私の単純な仮定は、「接続：キープアライブ」は実際にはもう使用されるべきではないということです。しかし、それはまだ健在のようです。たとえば、keep-aliveは次のクエリで返されます。

私の質問は：なぜConnection：keep-aliveがまだHTTPヘッダーで指定されているのですか？

当然の質問は次のとおりです。HTTP/1.0とそのバリアントのみを話す（クライアント、サーバー、プロキシなど）はまだありますか、それとも2011年の時点でそのようなエンティティのほとんどはHTTP / 1.1上にありますか？

これが私の作業仮説です：

1）HTTP / 1.0は使用されなくなり、「何年も前」のb /c

2）（1）を考えると、keep-aliveはもう使用すべきではありませんが、純粋に痕跡的な理由で使用されます（つまり、特定のテクノロジーがそれを削除したり、ブードゥーコードとして保持したりすることはありません）。

（1）が正しくなく、HTTP / 1.0がまだ使用されている場合は、HTTP 1.0-1.1の相互運用に関するフォローアップの質問にもかかわらず、キープアライブを使用し続けることが妥当であると思われます。

洞察を共有してくれてありがとう！

ASP.NET で以下を実装する最良の方法を知りたかったのです。私はこれらのディレクティブを使用したことがないので、サンプル コードを教えていただければ非常に助かります。

1. HTTP/1.0 プラグマ ヘッダー
2. HTTP/1.1 キャッシュ - コントロール ヘッダー
3. 過去の有効期限ヘッダー

IE を除くすべてのブラウザーで動作するオーディオおよびビデオ プレーヤー (フラッシュ フォールバックを備えた html5) を含めました。

問題を探しているときに、サーバーが "HTTP/1.0 200 OK" および "Connection:close" ヘッダーを送信する (および Content-Length を送信しない) ことがわかりましたが、IE のみで、一部のファイル (.swf、.mp3 および.mp4)。

これらのファイルの gzip を無効にするために、以下を .htaccess に追加しました。

私はApache構成の経験がなく、一部のリクエストに別のhttpバージョンを使用する必要がある理由がわかりません。

送信ヘッダーは次のとおりです。

および応答ヘッダー:

更新:最初のページ要求 (PHP、text/html) 応答も HTTP/1.0 であることがわかりましたが、後続のすべての ajax 要求ではありません。

問題

Node.JS を介して不明な長さのリソースを提供しています。このため、Content-Lengthヘッダーを設定できません。HTTP 1.1 の場合、この性質のリソースにはチャンク エンコーディングを使用する必要があります。Node.JS はこれを認識しており、次のヘッダーを使用して、独自のチャンク転送エンコーディングでデータを送信します。

これはすべて問題なく、行儀の良いクライアントに適しています。 ただし、動作があまり良くないクライアント (つまり、Android 2.2 以前) をサポートする必要があります。 これらのクライアントは、チャンク転送エンコーディングを適切にサポートしていません。

修正試行 #1

私の最初の考えは、エンコーディングをnone次のように設定することでした:

これにより、Node.JS の自動チャンク エンコーディングが無効になり、ほとんどのクライアントとの互換性が維持されます。しかし、Android 2.3 以降のクライアントは、このような偽の転送エンコード ヘッダーが表示されると咳をして窒息するだけなので、壊れてしまいました。

試行番号 2 を修正 (助けが必要な場合)

でリクエストを行うとHTTP/1.0、サーバーはチャンクエンコーディングなしで適切にレスポンスを返します:

これで問題は解決し、面倒なすべてのクライアントに対して機能するストリームを提供できるようになりました。の偽のヘッダーを送信する必要はありTransfer-Encodingません。また、コンテンツの長さを指定する必要もありません。

Node.JS の HTTP サーバーが常に HTTP/1.0 モードでサービスを提供するように強制するにはどうすればよいですか?

net.socketまたはhttp.requestでHTTP-1.0リクエストを作成したいのですが、このコードに問題があります。

同じエラーが発生します：

あなたの助けは大歓迎です。

GET http://d9.c4.b1.a0.top.list.ru/ HTTP/1.0\r\nHost: d9.c4.b1.a0.top.list.ru\r\n\r\n

応答：

応答：

これらのクエリの違いは何ですか?

PS クエリは を使用して作成されましたtelnet。

私のデバイスには、POST HTTP/1.0 要求を送信するための UBlox (ハードウェア コンポーネント) があります。

Tomcat で受け取るヘッダーは次のとおりです。

リクエストボディは実際にはバイナリデータです。Tomcat はクライアントに 400 を返すだけで、ヘッダーや本文などを出力するだけのサーブレットも実行しません。

ヘッダーの問題ではないようです。データに何か問題があるはずだと思います。それでも、Tomcat が 400 を返し、サーブレットに制御を渡さないのはなぜですか? どうすればこれをデバッグできますか?