feat(blog/content): new post /posts/2025-03-28/http-1-1-send-multiple-same-headers/

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="&copy; 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 &quot;field-name: field-value&quot; 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>&quot;field-name: field-value&quot;</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 &quot;Set-Cookie&quot; 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 &quot;Set-Cookie&quot; 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">
+      &copy; 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="&copy; 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">
+      &copy; 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>