4

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

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

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

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

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

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

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36

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

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

4

3 に答える 3

4

いいえ、コンマに基づいてヘッダーを分割するのは安全ではありません。例として、Accept: foo/bar;p="A,B,C", bob/dole;x="apples,oranges"は有効なヘッダーですが、MIME タイプのリストを取得する目的でカンマで分割しようとすると、無効な結果が得られます。

正解は、各ヘッダーが ABNF を使用して指定されていることです。それらのほとんどはさまざまな RFC で指定されています。たとえば、RFC7231 セクション 5.3.2Accept:で定義されています。

私はこの特定の問題を抱えており、パーサーを作成してエッジケースでテストしました。ヘッダーを解析するだけでなく、それを解釈して正しい結果を出すことも簡単ではありません。

一部のヘッダーは他のヘッダーよりも複雑ですが、基本的に各ヘッダーには独自の文法があり、正しい (そして安全な) 処理のために尊重する必要があります。

于 2016-02-04T04:40:56.683 に答える
1

そのヘッダー フィールドのフィールド値全体がコンマ区切りのリスト [つまり、#(値)] として定義されている場合

だから、それは逆です。が+Field: value1, value2と同等であると想定できるのは、 が をサポートしている、つまりコンマ区切りの値のリストであると仕様に記載されている場合のみです。Field: value1Field: value2Field#(value)

于 2015-04-09T21:38:00.063 に答える
0

仕様を読んで、次のヘッダーが複数の (カンマ区切りの) 値をサポートしていると結論付けました。

  • 承認
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Accept-パッチ
  • 許容範囲
  • 許可する
  • キャッシュ制御
  • 繋がり
  • コンテンツ エンコーディング
  • コンテンツ言語
  • 予想
  • イフマッチ
  • 一致しない場合
  • プラグマ
  • プロキシ認証
  • テ
  • トレーラー
  • 転送エンコーディング
  • アップグレード
  • 変化
  • 経由
  • 警告
  • WWW 認証
  • X-Forwarded-For

これを使用して、分割可能なヘッダーのホワイトリストを作成できます。

于 2015-04-09T23:19:11.627 に答える