問題タブ [rfc2616]

204 HTTP ステータス コードの使用例を理解するのに苦労しています。RFC2616 は次のように述べています。

10.2.5 204 コンテンツなし

サーバーは要求を満たしましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。レスポンスには
、新しいメタ情報または更新されたメタ情報がエンティティ ヘッダーの形式で含まれる場合があります。エンティティ ヘッダーが存在する場合は、 リクエストされたバリアント
に関連付ける必要があります。

クライアントがユーザー エージェントである場合、リクエストが送信された原因となったドキュメント ビューを変更すべきではありません (SHOULD NOT)。この応答は主に、ユーザー エージェントのアクティブなドキュメント ビューを変更せずにアクションの入力を許可することを目的としていますが、現在ユーザー エージェントのアクティブなビューにあるドキュメントには、新しいメタ情報または更新されたメタ情報を適用する必要があります。

204 応答にはメッセージ本文を含めてはならない (MUST NOT) ため、常にヘッダー フィールドの後の最初の空行で終了します。

「ドキュメント ビュー」は DOM を参照していますか?

たとえば、ユーザーを削除する AJAX リクエストを発行し、ページを更新してリクエストが正常に完了したらリストからユーザーを削除した場合、サーバーは応答として {} を含む 200 を返すか、{} を含まない 204 を返します。体 ？

編集：私の主な懸念は、「クライアントがユーザーエージェントである場合、リクエストが送信された原因となったドキュメントビューを変更すべきではない」に関連しています。部。私自身の言葉で再定式化するには: 204 を返す場合、DOM を更新できますか?

HEAD がリソースに送信され、サーバーがチャンク エンコーディングを実行することを決定した場合、HTTP サーバーの応答はどのようになるかについて質問があります。

サーバーが特定のリソースで GET のチャンク エンコーディングを常に実行したい場合、応答の生成中に正確なコンテンツの長さがわからないため、同じリソースで HEAD が送信されたときにサーバーはどのように動作する必要があります。

ブラウザーはリクエストのリダイレクト先の場所をキャッシュしますか? 例えば。

私のテストから、そうではないと結論付けましたが、確認したいと思います。

HTTP 接続のクローズについて 2 つの質問があります。

1. クライアントが Connection: close で HTTP 要求を送信する場合、クライアントが応答を受信した後に TCP FIN を送信するのは、HTTP サーバーまたはクライアントの責任ですか?

2. クライアントが不適切な形式の HTTP リクエストを送信し、サーバーが 400 BAD REQUEST を送信する場合、サーバーで接続を閉じるのがベスト プラクティスですか (HTTP リクエストに接続: keep-alive がある場合でも)、それとも接続を維持するのがベスト プラクティスですか?まだ活動中？

私の質問に答えてくれてありがとう？

サーバーに HTTP を実装しようとしていますが、複数のトレーラー ヘッダー フィールド (チャンク エンコーディングを使用) の処理方法に関する情報が見つかりません。

標準 ( https://www.rfc-editor.org/rfc/rfc2616#section-14.40 ) は次のように述べています。トランスファーコーディング」。

ただし、このヘッダーで複数のヘッダーを指定する方法については何も示していませんTrailer。

たとえば、リクエストまたはレスポンスに と の 2 つのトレーラー ヘッダーがある場合、ヘッダーExample1をExample2どのように構成しTrailerますか?

このように：Trailer: Example1 Example2またはTrailer: Example1,Example2または何？

ログを保持するために CouchDB を使用したいと思います (理由は聞かないでください ;-))。CouchDB の添付機能を利用したいと思います。多くのログがありますが、各ログはかなり小さく、1Mb を超えるものはないと思います (通常は数 Kb の範囲です)。

AFAICS いくつかのオプションがあります。

1. サーバー側でログを蓄積し、ログ全体を一度に添付ファイルとしてサーバーにプッシュできますが、すぐには利用できないことを意味します:-(
2. ログを定期的にプッシュすることもできますが、ログを更新するには再度ダウンロードして詳細情報を添付し、CouchDB にプッシュする必要があります。

私はこれらの解決策のどちらにもあまり満足していません.

GET リクエストの場合、CouchDBは (Content-)Range ヘッダーを明確にサポートしています ( RFC 2616によると、標準ヘッダーではないようです)。RFC 2616 も Content-Range を GET リクエストのみに制限していません (この意見は他のユーザーと共有されているようです)。

したがって、問題は、CouchDB が PUT 要求に対してもこれをサポートするかどうかです。この場合、私のユースケースに理想的なアタッチメントに取り付けることができます:-)

HTTPヘッダーを解析しています。ヘッダー値を意味のある配列に分割したいと思います。

たとえば、Cache-Control: no-cache, no-storeを返す必要があり['no-cache','no-store']ます。

HTTP RFC2616 は次のように述べています。

同じフィールド名を持つ複数のメッセージ ヘッダー フィールドは、そのヘッダー フィールドのフィールド値全体がコンマ区切りのリスト [つまり、#(値)] として定義されている場合にのみ、メッセージに存在する場合があります。メッセージのセマンティクスを変更せずに、複数のヘッダー フィールドを 1 つの「フィールド名: フィールド値」のペアに結合できなければなりません。これには、後続の各フィールド値を最初のフィールド値に追加し、それぞれをコンマで区切ります。したがって、同じフィールド名を持つヘッダー フィールドが受信される順序は、結合されたフィールド値の解釈にとって重要であり、メッセージが転送されるときにプロキシはこれらのフィールド値の順序を変更してはなりません (MUST NOT)。

しかし、その逆が正しいかどうかはわかりません。コンマで分割しても安全ですか?

これが問題を引き起こす一例をすでに見つけました。たとえば、私の User-Agent 文字列は

つまり、「KHTML」の後にコンマが含まれています。明らかに、私は複数のユーザー エージェントを持っていないので、このヘッダーを分割しても意味がありません。

User-Agent 文字列は唯一の例外ですか、それとも他にもありますか?