問題タブ [rfc2616]

RFC 2616から、HTTPクライアントがContent-Length：0またはTransfer-Encoding：チャンクヘッダーを含む204NoContent応答を受け入れる必要があるかどうかを判断できません。これらのヘッダーは、一部のHTTPクライアントとプロキシを破壊しているように見えます。これらは明らかに空の応答本文を読み取ろうとしますが、仕様では次のようになっています。

1. 「MUSTNOT」にメッセージ本文が含まれる応答メッセージ（1xx、204、304応答、HEAD要求への応答など）は、エンティティに関係なく、常にヘッダーフィールドの後の最初の空行で終了します。メッセージに存在するヘッダーフィールド。

私にとって、「エンティティヘッダーフィールドに関係なく」は、クライアントがこの状況を許容する必要があることを意味します。ErlangHTTPライブラリはこの解釈を選択しました。ただし、lighttpdとIBMは反対の解釈を選択しました。つまり、本文を持つことが禁止されている応答に対して、サーバーにこれらのヘッダーを含めないようにする必要があります。

したがって、Webアプリケーションはこれらのヘッダーを応答から削除する必要がありますか、それともネットワークインフラストラクチャとクライアントは204コンテンツなし、304変更なしなどでこれらのヘッダーを許容する必要がありますか？

Content-Type ヘッダーに charset パラメータが指定されていない場合、RFC2616 セクション 3.7.1は、サブタイプ「テキスト」のメディア タイプに対して ISO8859-1 を想定する必要があることを暗示しているようです。

明示的な文字セット パラメータが送信者によって提供されない場合、「テキスト」タイプのメディア サブタイプは、HTTP 経由で受信したときにデフォルトの文字セット値「ISO-8859-1」を持つように定義されます。

「ISO-8859-1」またはそのサブセット以外の文字セットのデータは、適切な文字セット値でラベル付けする必要があります。

ただし、「application/x-javascript」のような Content-Type 値 (つまり、charset パラメータなし) を持つ Javascript ファイルを提供するアプリケーションを日常的に目にします。これらのスクリプトに非 ASCII UTF-8 文字が含まれている場合でも、解釈されると破損します。 ISO8859-1として。

これにより、クライアントに問題が発生することはないようです。クライアントはバイトを UTF-8 として解釈することをどのように認識しますか? UTF-8 がデフォルトであることを意味する他の文字データ サブタイプのルールはありますか? これはどこに文書化されていますか?

WinHttpReadDataのドキュメントには、 HTTP のチャンク転送コーディングに関して次のように書かれています。

Windows Vista および Windows Server 2008 以降、WinHttp を使用すると、アプリケーションはサーバーに送信されたデータに対してチャンク転送エンコードを実行できます。Transfer-Encoding ヘッダーが WinHttp 応答に存在する場合、WinHttpReadData はデータをアプリケーションに渡す前にチャンク情報を取り除きます。

誰でもこれを解読できますか？

Q1まず、このテキストは WinHttpReadData のページにあります。これは、... HTTP クライアント アプリケーション内でデータ、具体的には応答データを読み取るために使用されます。それで、それが言うとき、それはどういう意味ですか

Windows Vista および Windows Server 2008 以降、WinHttp を使用すると、アプリケーションはサーバーに送信されたデータに対してチャンク転送エンコードを実行できます。

WinHttpReadData 関数は、サーバーに送信されるデータでは使用されません。サーバーからデータを読み取るときに使用されます。

HTTP 要求の一部としてサーバーにデータを送信するために使用される WinHttpWriteData 関数のドキュメントを参照すると、チャンク転送機能については言及されていません。

Q2新しいチャンク転送サポートが何を意味するかを把握したとしたら、どうすればそのサポートを得ることができますか? Vista と WS2008 で新しいと書かれています。WS2003 で実行され、WinHttpReadData を使用するアプリを作成し、チャンクされた応答または WinHttpWriteData に遭遇し、チャンクされた要求を送信したい場合はどうなりますか?

行間で、このドキュメントは、Vista 時代の Windows SDK 以降の WinHttp.lib に対してリンクする必要があると言っていますか? それともWS2003では本当に無理なのでしょうか? つまり、このライブラリを使ってチャンク転送を行うアプリは、指定されたOSで動作しなければならないということでしょうか?

これは暴言のように聞こえるかもしれませんが、そうではありません。本当に知りたいです。

私にとって、HTTP 1.1 RFC とその周辺のさまざまな実装の最も弱い点の 1 つは、100 の Continue ヘッダーを処理する方法です。

私はしばらくウェブを検索し、さまざまな実装を調べました。ただし、よくわからないことが 1 つあります。100 Continue メッセージの正しい構文は何ですか? いくつかの情報源は、これは追加のヘッダー行のない単一の応答行でなければならないと主張しています。ただし、RFC 2616 に反映されていることがわかりません。では、何が正しいのでしょうか。

また

?

パケットから直接 HTTP データを解析しています (TCP が再構築されているかどうかに関係なく、そうであると想定できます)。

HTTP をできるだけ正確に解析するための最良の方法を探しています。

ここでの主な問題は、HTTP ヘッダーです。

HTTP/1.1の基本的なRFC を見ると、HTTP ヘッダーの解析が複雑になるようです。RFC では、ヘッダーのさまざまな部分の非常に複雑な正規表現について説明しています。

HTTP ヘッダーのさまざまな部分を解析するには、これらの正規表現を作成する必要がありますか?

これまでに書いた HTTP ヘッダーの基本的な解析は、一般的な HTTP ヘッダー用です。

また、セクション 4.2 で説明したように、内部をカンマ区切りの値に置き換えLWS、繰り返しSPヘッダーを同じものに置き換えました。field-name

ただし、たとえばセクション 14.9 を見ると、さまざまな部分を解析するfield-valueには、はるかに複雑な解析スキームが必要であることがわかります。

field-valueパーサーのユーザーに HTTP のすべての機能を提供し、HTTP のすべての部分を解析したい場合、HTTP 解析の複雑な部分 (特に ) をどのように処理する必要があると思いますか?

このための設計提案も高く評価されます。

ありがとう。

この質問は、すべてが同じ重みであり、私のブログのこのコメントによって促された場合のHTTPヘッダー「Accept-Encoding」のメディアタイプの優先順位に関するものです。

バックグラウンド：

Accept-Encodingヘッダーは、ブラウザが受け入れることができるメディアタイプのコンマ区切りリストを取ります（例：gzip、deflate）

他のメディアタイプを優先するように品質係数を指定することもできます。たとえば、「gzip; q = .8、deflate」の場合、deflateが優先されますが、この質問には関係ありません。注意：「q = 0」のタイプは、「受け入れられない」ことを意味します。

RFC2616は、メディアタイプ定義の「最も具体的な参照」を最初に重み付けする必要があるとも述べています。つまり、「text/html」ではなく「text/html; level=1」を使用する必要があります。これは質問にも関係ありません。

質問：

次の場合、どのメディアタイプが優先されますか？

どちらのタイプも同等の品質係数1を持ち、どちらのタイプもブラウザに「許容可能」であるため、どちらかを使用できます。入力された最初のタイプは「優先」されるべきだといつも思っていましたが、 RFCにはこの特定のケースの特定の例や優先はないようです。

JavaでHTTPクライアントを実装する必要がありますが、私のニーズでは、HTTPパイプラインを実装するのが最も効率的な方法のようです（RFC2616による）。

余談ですが、POSTをパイプライン化したいと思います。（また、多重化について話しているのではありません。パイプラインについて話しているのです。つまり、HTTP要求の応答バッチ処理を受信する前に、1つの接続を介して多くの要求を処理します）

パイプラインをサポートしていることを明示的に示しているサードパーティのライブラリが見つかりませんでした。しかし、たとえばApache HTTPCoreを使用してそのようなクライアントを構築することも、必要に応じて自分で構築することもできます。

私が抱えている問題は、それが良い考えであるかどうかです。HTTPパイプラインは理論モデル以上のものであり、HTTPサーバーによって適切に実装されているという信頼できる参照は見つかりませんでした。さらに、パイプラインをサポートするすべてのブラウザでは、デフォルトでこの機能がオフになっています。

したがって、そのようなクライアントを実装しようとすると、サーバーの実装（またはプロキシ）が原因で多くの問題が発生します。これらに関するガイドラインを提供する参考資料はありますか？

それが悪い考えである場合、効率のための代替プログラミングモデルは何でしょうか？個別のTCP接続？

同じリソースのリクエストに対して、HTTP サーバーが で応答したりVary: *、 で応答したりする理由はありますか?Vary: Foo

Foo両方の応答を受信 (およびキャッシュ) した後、一致するヘッダーを持つ要求を受信した場合、キャッシュはどうすればよいVary: Fooでしょうか? 一致する応答を提供できますか、それとも別のVary: *応答がそれをオーバーライドしますか?

サーバーが を返した場合、http クライアントは何をすべきCache-Control: private, publicですか?

privateをオーバーライドする必要があると感じていますpublicが、RFC で確認を見つけることができません ( MUSTinprivateとMAYin以外public)。

SOS SOS SOS お願いします!!! ポート 80 でリッスンし、Get メソッドを使用してファイルなど (127.0.0.1/index.html) を開くプリミティブな HttpServer を Java で作成しました。HTTP/1.1 (RFC 2616) プロトコルから要求ヘッダー (Accept、Accept Language、User-Agent) と応答ヘッダー (Content-Length および Cache-Control) を作成したいと考えています。その方法を教えてください...あなたは私の命を救うでしょう!!!!!!!! ありがとう！