hero-rinのブログ

某会社で某システムの運用、開発をやっているただのおじさん

トップ > 技術 > リダイレクトとHTTPステータスコードのお話

リダイレクトとHTTPステータスコードのお話

技術 プロトコル

リダイレクトでの注意点を書き残す！

前回、AWSの費用まわりであまりの複雑さに知恵熱が出そうだったので、ここで少し骨休みを！ちょっと前にリダイレクトとHTTPステータスコードで「へー」と思ったことがあったのでここに残しておこうと思ったしだいです。

リダイレクト

ご存知リダイレクト。どっかのページに転送する時は皆さん使っていると思います。意外にどこにでも書けるので、使い勝手がいい半面あっちゃこっちゃで使うと想定と違う動きをしてしまいハマりまくるという経験をするので注意が必要だったりします。

こんなところに書いて飛ばしますよね。

HTTPステータスコード

HTTPステータスコードは3桁の数字でその時の状態をお知らせしてくれます。

リダイレクトとHTTPステータスコードの注意点

さて、こっからが本題です！HTTPはリダイレクト用として3xxのステータスコードを用意していて、リダイレクト設定する時は、この3xxを指定してリダイレクトを使います。ただこのステータスコード何も考えずに指定すると後々厄介な目にあったりするのです。ここではそれぞれの特徴と"何が厄介か？"として注意点を載せて行こうと思います。後おまけで、雑な感じなんですがnginxの設定例も載せときます。

301リダイレクト

HTTPステータスコード301を使用しリダイレクトを行う方法です。特徴と注意点はこんな感じでしょうか？

301の特徴
  • 恒久的に移動したい場合に使用します
  • GETにてリクエストを行う

完全に別の場所に移住する時に使用するリダイレクト方式です。

301の注意点
  • 転送先がindexされやすいです
  • 転送先のページがブラウザにキャッシュされます

上の注意点はやっかいなのでコード指定は慎重に、何が厄介かというと一定の期間だけ転送先にリダイレクトしたい時に301を使ってしまうとその一定期間が終わってリダイレクトの設定を解除してもGoogleなどの検索には転送先が引っかかり、転送元を表示しようとするとブラウザキャッシュで転送先が表示！なんて現象がおきてしまいます。

一応Chromeだけですが、キャッシュクリアの方法も載せときます。

  1. Ctrl + Shift + Delete
  2. 期間：全期間
  3. キャッシュされた画像とファイルにチェック（それ以外はチェック外しとく）
  4. 『データを削除ボタン』を押す
nginxの設定

rewriteを使うとこんな感じですね。www.example.comが転送元で、www.redirect.comが転送先です。

server {
  listen 80;
  server_name www.example.com;

  rewrite ^(.*)$ http://www.redirect.com$1 permanent;

}

公式ではreturnを推奨しているとのことなのでそちらも載せときます。

server {
  listen 80;
  server_name www.example.com;

  return 301 http://www.redirect.com$request_uri;

}

302リダイレクト

HTTPステータスコード302を使用しリダイレクトを行う方法です。こちらも特徴と注意点を書いていきます。

302の特徴
  • 期間限定（一時的）に移動したい場合に使用します
  • GETにてリクエストを行う

一時的な移動の場合は、302を使用します。

302の注意点
  • 転送元がindexされやすいです
  • ブラウザにキャッシュされないようです

恒久的な移転なのに302を指定していたりするといつまで経ってもGoogleなどの検索に転送元が引っかかったり毎回ブラウザの読み込みに時間がかかったりといった悲しい現象がおこったりします。

nginxの設定

301リダイレクトと大差ないんですが、こちらもrewriteとreturn二通り載せておきます。

server {
  listen 80;
  server_name www.example.com;

  rewrite ^(.*)$ http://www.redirect.com$1 redirect;

}

公式ではreturnを推奨しているとのことなのでそちらも載せときます。

server {
  listen 80;
  server_name www.example.com;

  return 302 http://www.redirect.com$request_uri;

}

その他のリダイレクト

自分は正直全然意識していなかったんですが、HTTPも常にバージョンが上がっていて2019年4月現在の最新はHTTP/3とのこと各種ブラウザもこのプロトコルを吸収していく形になるんだと思います。そんなHTTPですがステータスコードも着実に増えていて、現状は303, 307, 308なんてものが存在します。正直どんな時に使用するのかまだ想像できていませんが、特徴を記載して今回は終わりにしたいと思います。

303リダイレクト
  • HTTP/1.1から導入
  • 意味合い：他を参照せよ

リクエストに対するレスポンスは異なるURIの下で発見でき、その資源をGETメソッドを使って検索する必要がある。

規格の説明として上のような内容が書かれていたんですが、分かるような分からないような？という感じでモヤモヤします。こんな説明もありました。

新しいURLにはGETアクセスすることが決められたリダイレクト。

いろんな説明サイトを見て自分なりにこんな解釈になりました。

まず、掲示板サイトがあるとします。

『掲示板サイトで書き込み投稿する時のよくある例として書き込みフォームに何かしら"発言"を書き込んで、登録ボタンを押すと登録完了ページに飛んで登録完了！なんていうのがあるけど、その仕組として"発言"を書き込んで登録ボタンを押すタイミングでその情報がPOSTされて登録完了ページにリダイレクトされる。そんな時のステータスコードはPOSTで返しても意味ないので、GETでURIを返して貰った方がいい。』

こんな例の時に303リダイレクトを使うそうな。

307リダイレクト
  • HTTP/1.1から導入
  • 一時的リダイレクト

これ定義自体は302と同じです。どうも302が想定と違う使い方をされまくっていることから『POSTでリクエストした場合はPOSTで返す！』という縛りがキツイステータスコードを用意したみたいです。

308リダイレクト
  • HTTP/1.1から導入
  • 恒久的リダイレクト

これも定義は301と同じです。これも理由は307と同じで『GETで送ったらGETで、POSTで送ったらPOSTで！』というルールが追加されてます。

ちなみにその他のリダイレクトnginxでもちゃんと対応していてreturnでそのステータスコード書いてあげるとちゃんとそのステータスコードでリダイレクトしてくれるのでお試しあれ。

総括

現状リダイレクトは中々面倒くさいことになっている。というのも、そもそも各ブラウザがHTTPの約束ごとに準拠していないようなのです。特に307,308はPOSTでリダイレクトしてもほとんどのブラウザがGETで返しているとのこと、しかも携帯やスマホなどのモバイル端末はブラウザのバージョンが古くHTTP/1.1とか知りません！というブラウザがゴロゴロしている状態なので、新しいステータスコードが使いづらいという選別も面倒くささに拍車をかけてます。Windows10みたいに最新化をごり押す気概が必要なんだなと思いました。（Microsoftさん、早くIEを取り除いて下さい。m(_ _)m ）

そして言い訳

先週結構大きめなリリースがありまして、休日なんかも出勤なんかしてしまいブログ更新ができませんでした。AWSのサービスもコンスタントに書いていかないと終わりゃしないので頑張っていきたいと思います。

ではでは、今回はここまで！