🛺

初めて見た status code「308」、リダイレクトでおなじみの「301」と何が違うのか調べてみたのだ

に公開2

308 Redirect vs. 301 Redirect

301 Moved Permanentlyについては前の記事で触れているのだ

https://zenn.dev/hamuziro/articles/bf9e89cee47405#301-moved-permanently

HTTP response status codes については MDN Web Docs をみて欲しいのだ[1]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

TL;DR

実際には 301 Moved Permanently とほとんど同なのだ。

けれど、308 Permanent Redirectはリダイレクトされたリクエストにおいて、HTTPリクエストメソッドとボディが変更されないことを保証してくれる。

そのため、POST メソッドがリダイレクト先でも GET に予期せず変わったら困るという場面では 308 を使えるということを覚えておくと良さそうなのだ。

308 Permanent Redirect

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/308

特徴:HTTPメソッドの保持

308 Permanent Redirectは、リダイレクトされたリクエストにおいて、HTTPリクエストメソッドとボディが変更されないことを保証します。

例:POSTリクエストがリダイレクトされた場合、リダイレクト先にもPOSTで送信されるのだ

ほとんどのサイトのリクエストは主にGETであるため、実際には301と同じ

しかし、実際のWebサイトの多くはGETリクエストが中心[2]なため、ほとんどのケースで301と308の違いは表面化しないのだ。

以前ぼくが 308 という status code初めて出会ったきっかけの curl コマンドでの検証でもオプションをつけていなかったのでデフォルトの GET メソッドでリクエストをしていたのだ。

curl -I https://www.react.dev/
HTTP/2 308 
cache-control: public, max-age=0, must-revalidate
content-type: text/plain
date: Sun, 13 Jul 2025 22:57:22 GMT
location: https://react.dev/
...

背景:なぜ 308 が作成された?

HTTP 308リダイレクトは、その設計において fail-safe に近い考え方が取り入れられている

fail-safe とは

fail-safe とは、システムに障害が発生した場合や予期せぬ動作が起こった際に、安全側(より被害の少ない側)に動作するように設計されていることを指すのだ。

308リダイレクトの場合、この「予期せぬ動作」が、従来の301リダイレクトで起こりうる「HTTPメソッドの意図しない変更」なのだ。

  • HTTP 301 "Moved Permanently"は、リソースが恒久的に移動したことを示すステータスコードなのだ
  • だけど、HTTPの仕様上はメソッド変更を意図していないにもかかわらず、古いクライアントや一部の既存のユーザーエージェントは、POSTリクエストをGETリクエストに誤って変更してしまうことがあったのだ
  • これは、特にフォーム送信やAPIリクエストなど、POSTメソッドで送られたデータがリダイレクトによって失われる、あるいは意図しないGETリクエストに変換されるという問題を引き起こす可能性があったのだ
  • そこで、308リダイレクトを使うことでリダイレクトされたリクエストにおいて、HTTPリクエストメソッドとボディが変更されないことを「保証する」という安心感が得られるのだ

GoogleのJohn Mueller氏も、308リダイレクトは「技術的にはよりクリーン (technically cleaner)」だと述べており、サイトがどのような種類のリクエスト(GET、POSTなど)を受け取るか不確かな場合に役立つとコメントしていたと複数のブログサイトで言及しているようなのだ[3]

標準化の時期

301 Moved Permanently:

  • HTTP/1.0 (RFC 1945)の頃から存在するステータスコードなのだ[4]

308 Permanent Redirect:

  • 2015年に RFC 7538 で標準化された

参考文献さま

https://mohitsseotraining.com/blog/seo/308-redirect-vs-301/

https://www.semrush.com/blog/308-permanent-redirect/

https://www.youtube.com/watch?v=X_TmsOjVixU

https://linkilo.co/blog/308-vs-301-redirects/

関連記事

脚注
  1. もしくは「告白に学ぶ HTTP Status Code」とかもあってとっても面白いのでおすすめなのだ ↩︎

  2. これも非対称性なのだ。ほとんどの人のインターネットの使い方は、情報を「消費(ダウンロード)」することが中心なのだ。 ↩︎

  3. 一次情報にアクセスしたかったのだが、John Mueller氏の元の投稿は削除されたのか見つからなかったのだ。 ↩︎

  4. コメントでおしえていただいたのだ。301リダイレクトはHTTP/1.1から導入されたものではなく、その前身であるHTTP/1.0の時点から存在していたのだ。ちなみに、この HTTP/1.0 は大きな革命だったのだ。それ以前の HTTP/0.9 時代は非常にシンプルな設計だったのに対し、HTTP/1.0 でステータスコードやHTTPヘッダーなどの概念が導入され、HTTPの表現の幅がとてつもなく広がったのだ。この仕様は web が急速に広まって来ていた時代を背景に1996年に発行された RFC 1945 で文書化されており、このときすでに301リダイレクトのようなステータスコードもこのHTTP/1.0の時点からすでに存在していたのだと確認できるのだ。 ↩︎

Discussion

YuneKichiYuneKichi

301はHTTP/1.0 (RFC 1945)の頃から存在するステータスコードですね。
ただ、この時からすでに

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing user agents will erroneously change it into a GET request

と、POSTGETに置き換えられるUAがあることが書かれています。
※HTTP/1.0にはGETPOSTHEADしかメソッドがありません。

まあ、

Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URL.

とか書いていたら、GETに置き換えられるのも仕方がない気もします。
ハイパーリンクではPOSTを代替できないので。

ハム次郎ハム次郎

コメントありがとうございます!記事の修正をさせていただきました。

301はHTTP/1.1より前の HTTP/1.0の時代から既に標準化されていたというとても重要なことをご指摘いただき感謝しております。

大変勉強になりました🙇‍♀️