diff options
| -rw-r--r-- | vhosts/blog/content/posts/2025-03-28/http-1-1-send-multiple-same-headers.ndoc | 120 | ||||
| -rw-r--r-- | vhosts/blog/nuldoc.toml | 1 | ||||
| -rw-r--r-- | vhosts/blog/public/atom.xml | 10 | ||||
| -rw-r--r-- | vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html | 184 | ||||
| -rw-r--r-- | vhosts/blog/public/posts/atom.xml | 10 | ||||
| -rw-r--r-- | vhosts/blog/public/posts/index.html | 15 | ||||
| -rw-r--r-- | vhosts/blog/public/tags/http/atom.xml | 19 | ||||
| -rw-r--r-- | vhosts/blog/public/tags/http/index.html | 66 | ||||
| -rw-r--r-- | vhosts/blog/public/tags/index.html | 10 |
9 files changed, 433 insertions, 2 deletions
diff --git a/vhosts/blog/content/posts/2025-03-28/http-1-1-send-multiple-same-headers.ndoc b/vhosts/blog/content/posts/2025-03-28/http-1-1-send-multiple-same-headers.ndoc new file mode 100644 index 00000000..8f4f679b --- /dev/null +++ b/vhosts/blog/content/posts/2025-03-28/http-1-1-send-multiple-same-headers.ndoc @@ -0,0 +1,120 @@ +--- +[article] +uuid = "046e4412-bee8-4ffe-9876-6cbeaa0caf6b" +title = "【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか" +description = "HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。" +tags = [ + "http", +] + +[[article.revisions]] +date = "2022-08-18" +remark = "デジタルサーカス株式会社の社内記事として公開" +isInternal = true + +[[article.revisions]] +date = "2025-03-28" +remark = "ブログ記事として一般公開" +--- +<article> + <note> + この記事は、2022-08-18 に<a href="https://www.dgcircus.com/">デジタルサーカス株式会社</a> の社内 Qiita Team に公開された記事をベースに、加筆修正して一般公開したものです。 + </note> + <section id="intro"> + <h>はじめに</h> + <p> + HTTP version 1.1 で同じ名前のヘッダを2回送ると、どのように解釈されるのか。仕様を確認した。 + </p> + <p> + 今回読んだ仕様は RFC 7230 で、こちらのリンクから閲覧できる: https://datatracker.ietf.org/doc/html/rfc7230 + </p> + <p> + その中でも、https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2 を主に引用する。 + </p> + <p> + ところで、HTTP 周りの仕様を探すときはここから飛ぶと便利: https://developer.mozilla.org/en-US/docs/Web/HTTP/Resources_and_specifications + </p> + </section> + <section id="specification"> + <h>仕様</h> + <section id="sender"> + <h>送信側</h> + <blockquote> + A sender MUST NOT generate multiple header fields with the same field + name in a message unless either the entire field value for that + header field is defined as a comma-separated list [i.e., #(values)] + or the header field is a well-known exception (as noted below). + </blockquote> + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 + 送信者は、同じ field name の header field を複数生成してはならない (MUST NOT)。 + ただし、header field の値がコンマ区切りのリストとして定義されているか、header field がよく知られた例外 (後述) である場合はその限りでない。 + </p> + </section> + <section id="recipient"> + <h>受信側</h> + <blockquote> + A recipient MAY combine multiple header fields with the same field + name into one "field-name: field-value" pair, without changing the + semantics of the message, by appending each subsequent field value to + the combined field value in order, separated by a comma. The order + in which header fields with the same field name are received is + therefore significant to the interpretation of the combined field + value; a proxy MUST NOT change the order of these field values when + forwarding a message. + </blockquote> + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 + 受信者は、同じ field name を持つ複数の header field を、メッセージの意味を変えないようにしつつ同じ順序で追加して、単一のコンマで区切られた <code>"field-name: field-value"</code> のペアに結合してよい (MAY)。 + したがって、同じ field name を持つ header field がどのような順序で受信されたかは、結合された値の解釈に影響する。 + よって、プロキシは、メッセージを転送する際、header field の順序を変えてはならない (MUST NOT)。 + </p> + </section> + <section id="exception"> + <h>例外ケース: Set-Cookie</h> + <blockquote> + Note: In practice, the "Set-Cookie" header field ([<a href="https://datatracker.ietf.org/doc/html/rfc6265">RFC6265</a>]) often + appears multiple times in a response message and does not use the + list syntax, violating the above requirements on multiple header + fields with the same name. Since it cannot be combined into a + single field-value, recipients ought to handle "Set-Cookie" as a + special case while processing header fields. (See Appendix A.2.3 + of [Kri2001] for details.) + </blockquote> + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 + 注意: 実際には、<code>Set-Cookie</code> header field (<a href="https://datatracker.ietf.org/doc/html/rfc6265">RFC6265</a>) は、しばしばレスポンスメッセージ中に複数回現れる。 + これはリストの構文を使っておらず、上述した同じ field name を持つ header field についての要件に違反している。 + この値は単一の値へ結合できないため、受信者は、header field を処理する際、<code>Set-Cookie</code> を特別扱いした方がよい。 + </p> + <p> + おそらく、「送信側」のところで書かれている「よく知られた例外」の一つがこれだと思われる。 + </p> + </section> + <section id="comma-separated-list"> + <h>どの header field がコンマ区切りのリストなのか</h> + <p> + 上記のように、同じ field name を持つ header field を複数回送れるかどうかは、その header field がコンマ区切りのリストとして定義されているかどうかで決まる。では、特定の header field がその条件を満たしているかどうか知りたいときは、何を見ればよいのか。 + </p> + <p> + HTTP の仕様として定義されているような header field であれば、下記のリンクからそれぞれの定義を参照できる。 + </p> + <ul> + <li>https://datatracker.ietf.org/doc/html/rfc7231#section-5</li> + <li>https://datatracker.ietf.org/doc/html/rfc7231#section-7</li> + </ul> + <p> + そうでない場合 (たとえば <code>X-</code> から始まるもの等) は、MDN や各ベンダのドキュメントを探すことになるだろう。 + </p> + </section> + </section> + <section id="outro"> + <h>まとめ</h> + <ul> + <li>送信側: 基本的には複数回送れない。コンマ区切りのヘッダは例外</li> + <li>受信側: 基本的には未規定。コンマ区切りのヘッダは複数回来たらその順に結合する</li> + <li>プロキシ: 順序を変えてはならない</li> + <li><code>Set-Cookie</code> は例外ケース</li> + </ul> + </section> +</article> diff --git a/vhosts/blog/nuldoc.toml b/vhosts/blog/nuldoc.toml index 0f0fbf1b..69283171 100644 --- a/vhosts/blog/nuldoc.toml +++ b/vhosts/blog/nuldoc.toml @@ -21,6 +21,7 @@ cpp = "C++" cpp17 = "C++ 17" gitlab = "GitLab" go = "Go" +http = "HTTP" isucon = "ISUCON" mncore-challenge = "MN-Core Challenge" neovim = "Neovim" diff --git a/vhosts/blog/public/atom.xml b/vhosts/blog/public/atom.xml index c9ea4064..06741fa1 100644 --- a/vhosts/blog/public/atom.xml +++ b/vhosts/blog/public/atom.xml @@ -7,7 +7,15 @@ <author> <name>nsfisis</name> </author> - <updated>2025-03-27T00:00:00+09:00</updated> + <updated>2025-03-28T00:00:00+09:00</updated> + <entry> + <id>urn:uuid:046e4412-bee8-4ffe-9876-6cbeaa0caf6b</id> + <link rel="alternate" href="https://blog.nsfisis.dev/posts/2025-03-28/http-1-1-send-multiple-same-headers/"></link> + <title>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</title> + <summary>HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。</summary> + <published>2025-03-28T00:00:00+09:00</published> + <updated>2025-03-28T00:00:00+09:00</updated> + </entry> <entry> <id>urn:uuid:99111377-27e7-427b-9dc5-a23f621fa826</id> <link rel="alternate" href="https://blog.nsfisis.dev/posts/2025-03-27/zip-function-like-command-paste-command/"></link> diff --git a/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html b/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html new file mode 100644 index 00000000..5b645245 --- /dev/null +++ b/vhosts/blog/public/posts/2025-03-28/http-1-1-send-multiple-same-headers/index.html @@ -0,0 +1,184 @@ +<!DOCTYPE html> +<html lang="ja-JP"> + <head> + <meta charset="UTF-8"> + <meta name="viewport" content="width=device-width, initial-scale=1.0"> + <meta name="author" content="nsfisis"> + <meta name="copyright" content="© 2025 nsfisis"> + <meta name="description" content="HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。"> + <meta name="keywords" content="HTTP"> + <meta property="og:type" content="article"> + <meta property="og:title" content="【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか｜REPL: Rest-Eat-Program Loop"> + <meta property="og:description" content="HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。"> + <meta property="og:site_name" content="REPL: Rest-Eat-Program Loop"> + <meta property="og:locale" content="ja_JP"> + <link rel="icon" type="image/svg+xml" href="/favicon.svg"> + <title>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか｜REPL: Rest-Eat-Program Loop</title> + <link rel="stylesheet" href="/style.css?h=79020a898c7052f79b32e90376a4497d"> + <link rel="stylesheet" href="/hl.css?h=340e65ffd5c17713efc9107c06304f7b"> + </head> + <body class="single"> + <header class="header"> + <div class="site-logo"> + <a href="/">REPL: Rest-Eat-Program Loop</a> + </div> + <nav class="nav"> + <ul> + <li> + <a href="/about/">About</a> + </li> + <li> + <a href="/posts/">Posts</a> + </li> + <li> + <a href="/slides/">Slides</a> + </li> + <li> + <a href="/tags/">Tags</a> + </li> + </ul> + </nav> + </header> + <main class="main"> + <article class="post-single"> + <header class="post-header"> + <h1 class="post-title">【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</h1> + <ul class="post-tags"> + <li class="tag"> + <a href="/tags/http/">HTTP</a> + </li> + </ul> + </header> + <div class="post-content"> + <section> + <h2 id="changelog">更新履歴</h2> + <ol> + <li class="revision"> + <time datetime="2022-08-18">2022-08-18</time>: デジタルサーカス株式会社の社内記事として公開 + </li> + <li class="revision"> + <time datetime="2025-03-28">2025-03-28</time>: ブログ記事として一般公開 + </li> + </ol> + </section> + <div class="admonition"> + <div class="admonition-label"> + NOTE + </div> + <div class="admonition-content"> + この記事は、2022-08-18 に<a href="https://www.dgcircus.com/" rel="noreferrer" target="_blank">デジタルサーカス株式会社</a> の社内 Qiita Team に公開された記事をベースに、加筆修正して一般公開したものです。 + </div> + </div> + + <section id="section--intro"> + <h2><a href="#section--intro">はじめに</a></h2> + <p> + HTTP version 1.1 で同じ名前のヘッダを2回送ると、どのように解釈されるのか。仕様を確認した。 + </p> + + <p> + 今回読んだ仕様は RFC 7230 で、こちらのリンクから閲覧できる: <a href="https://datatracker.ietf.org/doc/html/rfc7230" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc7230</a> + </p> + + <p> + その中でも、<a href="https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2</a> を主に引用する。 + </p> + + <p> + ところで、HTTP 周りの仕様を探すときはここから飛ぶと便利: <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Resources_and_specifications" rel="noreferrer" target="_blank">https://developer.mozilla.org/en-US/docs/Web/HTTP/Resources_and_specifications</a> + </p> + </section> + + <section id="section--specification"> + <h2><a href="#section--specification">仕様</a></h2> + <section id="section--sender"> + <h3><a href="#section--sender">送信側</a></h3> + <blockquote> + A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). + </blockquote> + + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 送信者は、同じ field name の header field を複数生成してはならない (MUST NOT)。ただし、header field の値がコンマ区切りのリストとして定義されているか、header field がよく知られた例外 (後述) である場合はその限りでない。 + </p> + </section> + + <section id="section--recipient"> + <h3><a href="#section--recipient">受信側</a></h3> + <blockquote> + A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message. + </blockquote> + + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 受信者は、同じ field name を持つ複数の header field を、メッセージの意味を変えないようにしつつ同じ順序で追加して、単一のコンマで区切られた <code>"field-name: field-value"</code> のペアに結合してよい (MAY)。したがって、同じ field name を持つ header field がどのような順序で受信されたかは、結合された値の解釈に影響する。よって、プロキシは、メッセージを転送する際、header field の順序を変えてはならない (MUST NOT)。 + </p> + </section> + + <section id="section--exception"> + <h3><a href="#section--exception">例外ケース: Set-Cookie</a></h3> + <blockquote> + Note: In practice, the "Set-Cookie" header field ([<a href="https://datatracker.ietf.org/doc/html/rfc6265" rel="noreferrer" target="_blank">RFC6265</a>]) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of [Kri2001] for details.) + </blockquote> + + <p> + 【日本語訳 (私が訳したもので、公式なものではない)】 注意: 実際には、<code>Set-Cookie</code> header field (<a href="https://datatracker.ietf.org/doc/html/rfc6265" rel="noreferrer" target="_blank">RFC6265</a>) は、しばしばレスポンスメッセージ中に複数回現れる。これはリストの構文を使っておらず、上述した同じ field name を持つ header field についての要件に違反している。この値は単一の値へ結合できないため、受信者は、header field を処理する際、<code>Set-Cookie</code> を特別扱いした方がよい。 + </p> + + <p> + おそらく、「送信側」のところで書かれている「よく知られた例外」の一つがこれだと思われる。 + </p> + </section> + + <section id="section--comma-separated-list"> + <h3><a href="#section--comma-separated-list">どの header field がコンマ区切りのリストなのか</a></h3> + <p> + 上記のように、同じ field name を持つ header field を複数回送れるかどうかは、その header field がコンマ区切りのリストとして定義されているかどうかで決まる。では、特定の header field がその条件を満たしているかどうか知りたいときは、何を見ればよいのか。 + </p> + + <p> + HTTP の仕様として定義されているような header field であれば、下記のリンクからそれぞれの定義を参照できる。 + </p> + + <ul> + <li> + <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-5" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc7231#section-5</a> + </li> + + <li> + <a href="https://datatracker.ietf.org/doc/html/rfc7231#section-7" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc7231#section-7</a> + </li> + </ul> + + <p> + そうでない場合 (たとえば <code>X-</code> から始まるもの等) は、MDN や各ベンダのドキュメントを探すことになるだろう。 + </p> + </section> + </section> + + <section id="section--outro"> + <h2><a href="#section--outro">まとめ</a></h2> + <ul> + <li> + 送信側: 基本的には複数回送れない。コンマ区切りのヘッダは例外 + </li> + + <li> + 受信側: 基本的には未規定。コンマ区切りのヘッダは複数回来たらその順に結合する + </li> + + <li> + プロキシ: 順序を変えてはならない + </li> + + <li> + <code>Set-Cookie</code> は例外ケース + </li> + </ul> + </section> + </div> + </article> + </main> + <footer class="footer"> + © 2021 nsfisis + </footer> + </body> +</html> diff --git a/vhosts/blog/public/posts/atom.xml b/vhosts/blog/public/posts/atom.xml index 209f0a66..8c05d6f2 100644 --- a/vhosts/blog/public/posts/atom.xml +++ b/vhosts/blog/public/posts/atom.xml @@ -7,7 +7,15 @@ <author> <name>nsfisis</name> </author> - <updated>2025-03-27T00:00:00+09:00</updated> + <updated>2025-03-28T00:00:00+09:00</updated> + <entry> + <id>urn:uuid:046e4412-bee8-4ffe-9876-6cbeaa0caf6b</id> + <link rel="alternate" href="https://blog.nsfisis.dev/posts/2025-03-28/http-1-1-send-multiple-same-headers/"></link> + <title>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</title> + <summary>HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。</summary> + <published>2025-03-28T00:00:00+09:00</published> + <updated>2025-03-28T00:00:00+09:00</updated> + </entry> <entry> <id>urn:uuid:99111377-27e7-427b-9dc5-a23f621fa826</id> <link rel="alternate" href="https://blog.nsfisis.dev/posts/2025-03-27/zip-function-like-command-paste-command/"></link> diff --git a/vhosts/blog/public/posts/index.html b/vhosts/blog/public/posts/index.html index 0c178934..b6887c5f 100644 --- a/vhosts/blog/public/posts/index.html +++ b/vhosts/blog/public/posts/index.html @@ -43,6 +43,21 @@ <h1>投稿一覧</h1> </header> <article class="post-entry"> + <a href="/posts/2025-03-28/http-1-1-send-multiple-same-headers/"> + <header class="entry-header"> + <h2>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</h2> + </header> + <section class="entry-content"> + <p> + HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。 + </p> + </section> + <footer class="entry-footer"> + <time datetime="2025-03-28">2025-03-28</time> 投稿 + </footer> + </a> + </article> + <article class="post-entry"> <a href="/posts/2025-03-27/zip-function-like-command-paste-command/"> <header class="entry-header"> <h2>zip 関数のようなコマンド paste</h2> diff --git a/vhosts/blog/public/tags/http/atom.xml b/vhosts/blog/public/tags/http/atom.xml new file mode 100644 index 00000000..9b7571f1 --- /dev/null +++ b/vhosts/blog/public/tags/http/atom.xml @@ -0,0 +1,19 @@ +<?xml version="1.0" encoding="utf-8"?> +<feed xmlns="http://www.w3.org/2005/Atom"> + <id>tag:blog.nsfisis.dev,2021:tag-http</id> + <title>タグ「HTTP」一覧｜REPL: Rest-Eat-Program Loop</title> + <link rel="alternate" href="https://blog.nsfisis.dev/tags/http/"></link> + <link rel="self" href="https://blog.nsfisis.dev/tags/http/atom.xml"></link> + <author> + <name>nsfisis</name> + </author> + <updated>2025-03-28T00:00:00+09:00</updated> + <entry> + <id>urn:uuid:046e4412-bee8-4ffe-9876-6cbeaa0caf6b</id> + <link rel="alternate" href="https://blog.nsfisis.dev/posts/2025-03-28/http-1-1-send-multiple-same-headers/"></link> + <title>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</title> + <summary>HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。</summary> + <published>2025-03-28T00:00:00+09:00</published> + <updated>2025-03-28T00:00:00+09:00</updated> + </entry> +</feed> diff --git a/vhosts/blog/public/tags/http/index.html b/vhosts/blog/public/tags/http/index.html new file mode 100644 index 00000000..53a57f48 --- /dev/null +++ b/vhosts/blog/public/tags/http/index.html @@ -0,0 +1,66 @@ +<!DOCTYPE html> +<html lang="ja-JP"> + <head> + <meta charset="UTF-8"> + <meta name="viewport" content="width=device-width, initial-scale=1.0"> + <meta name="author" content="nsfisis"> + <meta name="copyright" content="© 2025 nsfisis"> + <meta name="description" content="タグ「HTTP」のついた記事またはスライドの一覧"> + <meta name="keywords" content="HTTP"> + <meta property="og:type" content="article"> + <meta property="og:title" content="タグ「HTTP」一覧｜REPL: Rest-Eat-Program Loop"> + <meta property="og:description" content="タグ「HTTP」のついた記事またはスライドの一覧"> + <meta property="og:site_name" content="REPL: Rest-Eat-Program Loop"> + <meta property="og:locale" content="ja_JP"> + <link rel="alternate" type="application/atom+xml" href="https://blog.nsfisis.dev/tags/http/atom.xml"> + <link rel="icon" type="image/svg+xml" href="/favicon.svg"> + <title>タグ「HTTP」一覧｜REPL: Rest-Eat-Program Loop</title> + <link rel="stylesheet" href="/style.css?h=79020a898c7052f79b32e90376a4497d"> + </head> + <body class="list"> + <header class="header"> + <div class="site-logo"> + <a href="/">REPL: Rest-Eat-Program Loop</a> + </div> + <nav class="nav"> + <ul> + <li> + <a href="/about/">About</a> + </li> + <li> + <a href="/posts/">Posts</a> + </li> + <li> + <a href="/slides/">Slides</a> + </li> + <li> + <a href="/tags/">Tags</a> + </li> + </ul> + </nav> + </header> + <main class="main"> + <header class="page-header"> + <h1>タグ「HTTP」一覧</h1> + </header> + <article class="post-entry"> + <a href="/posts/2025-03-28/http-1-1-send-multiple-same-headers/"> + <header class="entry-header"> + <h2>【HTTP】HTTP/1.1 で同じヘッダを2回送るとどうなるか</h2> + </header> + <section class="entry-content"> + <p> + HTTP/1.1 で同じヘッダを2回送ったときの挙動について仕様を読んでまとめた。 + </p> + </section> + <footer class="entry-footer"> + <time datetime="2025-03-28">2025-03-28</time> 投稿 + </footer> + </a> + </article> + </main> + <footer class="footer"> + © 2021 nsfisis + </footer> + </body> +</html> diff --git a/vhosts/blog/public/tags/index.html b/vhosts/blog/public/tags/index.html index 8ec49766..8a6bfde5 100644 --- a/vhosts/blog/public/tags/index.html +++ b/vhosts/blog/public/tags/index.html @@ -122,6 +122,16 @@ </a> </article> <article class="post-entry"> + <a href="/tags/http/"> + <header class="entry-header"> + <h2>HTTP</h2> + </header> + <footer class="entry-footer"> + 1件の記事 + </footer> + </a> + </article> + <article class="post-entry"> <a href="/tags/isucon/"> <header class="entry-header"> <h2>ISUCON</h2> |