リダイレクトコード[301と302]動作を理解する
概要
こんにちは🙌
普段なんとなくHTTPステータスコードを見て、300番台が返ってきたら、リダイレクトされているとは分かっていましたが、いざ実装するとなると、果たしてどれを使うべきなのか。
301 Moved Permanently、302 Found、恒久的なリダイレクトと一時的なリダイレクトをどう使い分けるべきなのか、整理しておきます。
動作以外にも、公開されているサイトのSEOにも関わりますので、その辺りも少し調べてみます。
ゴール
HTTPステータスコードの動作を試しながら理解する。
試してみた
今回はALBで設定ができるリダイレクトを用いて、他のリソース(S3)にアクセスするような構成を取ります。
ALBでは以下2つのリダイレクトを設定出来ますね。
301 Moved Permanently
Locationヘッダーで示されたURLへ完全に移動します。
リダイレクト元のURLに戻る必要がない、恒久的な移動を意味しています。これは、SEO/クライアントブラウザでのキャッシュでの扱われ方を理解すると分かりやすくなる気がします。
1度HTTPSに変換するためCloudFrontでリダイレクトがかかっていますが、確かにLocationで転送先が返されていることが分かります。
$ curl -I -L example-alb-2057151030.ap-northeast-1.elb.amazonaws.com/index.html
HTTP/1.1 301 Moved Permanently
Server: awselb/2.0
Date: Sun, 24 Mar 2024 14:29:02 GMT
Content-Type: text/html
Content-Length: 134
Connection: keep-alive
Location: http://d496kuf7idiqt.cloudfront.net:80/index.html
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Sun, 24 Mar 2024 14:29:02 GMT
Content-Type: text/html
Content-Length: 167
Connection: keep-alive
Location: https://d496kuf7idiqt.cloudfront.net/index.html
X-Cache: Redirect from cloudfront
Via: 1.1 cf2960ce52c75f72f0d9c2ce5a90ba10.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: NRT20-C3
X-Amz-Cf-Id: 9z8hW8qP59_HzzRsYSmE263LibNFYo_vUF5H5bkl0IXZWBekvZWj0w==
HTTP/2 200
content-type: text/html
content-length: 227
date: Sun, 24 Mar 2024 14:29:03 GMT
last-modified: Sun, 24 Mar 2024 03:31:35 GMT
etag: "feba1a45e4a2e48932fcf9475c0995ae"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 d8c928873f156b774d8672a0fe24a434.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C3
x-amz-cf-id: iFV0vOAE_Yu1CTRekVzJSo5zeyd5HpZ8qmqGJJdsdvlDMuRTohgSuQ==
ブラウザで確認してみます。
続いて、ALBのレスポンスを固定レスポンスに変えます。
ブラウザを終了して、再度アクセスしてみても変更されておらず、301のリダイレクトが行われます。
SEOについては、以下のような説明があります。
ブラウザーはこのページにリダイレクトし、検索エンジンはリソースへのリンクを更新します (「SEO 用語」では、「リンクジュース」が新しい URL に送られたと言われます)。
つまり、301でリダイレクト設定をいれることによって、サイトが引き継がれたと検索エンジンで判断がされるため、次に紹介する302よりも早いタイミングでSEO評価が引き継がれることになります。RSSリーダーや他のクローラーも同様の動作をします。
302 Found
リクエストされたリソースは一時的にLocationヘッダで示されたURLへ移動します。
$ curl -I -L example-alb-2057151030.ap-northeast-1.elb.amazonaws.com/index.html
HTTP/1.1 302 Moved Temporarily
Server: awselb/2.0
Date: Sun, 24 Mar 2024 14:53:11 GMT
Content-Type: text/html
Content-Length: 110
Connection: keep-alive
Location: http://d496kuf7idiqt.cloudfront.net:80/index.html
HTTP/1.1 301 Moved Permanently
Server: CloudFront
Date: Sun, 24 Mar 2024 14:53:11 GMT
Content-Type: text/html
Content-Length: 167
Connection: keep-alive
Location: https://d496kuf7idiqt.cloudfront.net/index.html
X-Cache: Redirect from cloudfront
Via: 1.1 4b93c15bdfb93d7749719f6a48f1f7de.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: NRT20-C3
X-Amz-Cf-Id: TiWchlwdEVt_BlnlB3ZPd67za7_3xjck9P3_99Smnm2H1PnLvtqrQQ==
HTTP/2 200
content-type: text/html
content-length: 227
date: Sun, 24 Mar 2024 14:53:12 GMT
last-modified: Sun, 24 Mar 2024 03:31:35 GMT
etag: "feba1a45e4a2e48932fcf9475c0995ae"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 d8c928873f156b774d8672a0fe24a434.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C3
x-amz-cf-id: LZuuozk3CVotXnizGzrp73NpdthIEt8IBJ_ZruK_sFreAyxLdAzdQw==
ブラウザでの動作も確認してみます。
302でリダイレクトされていることが分かります。
ALBの設定を変更して、固定レスポンスで503エラーを返すように変更しました。
ALBにアクセスをしている状態だったので、そのまま画面更新を繰り返すと想定通りに503エラーを確認することが出来ました。
先程までの301 Moved Permanentlyとは動作が異なることが確認できます。
SEOについては、以下のような説明になっています。
ブラウザーはこのページにリダイレクトしますが、検索エンジンはリソースへのリンクを更新しません (「SEO 用語」では、「リンクジュース」が新しい URL に送られなかったと言われます)。
301とは異なり、検索エンジンはリダイレクト先のサイトを引き継がれた先と判断しないことになるようです。
- 補足
ちなみにPOSTメソッドのままリダイレクトさせる場合については、307 Temporary Redirectを使うことが推奨されています。307はリダイレクトされたリクエストが行われるときに、メソッドと本文が変更されないことが保証されるためとなります。
GETメソッドは変更されませんが、他のメソッドはGETメソッドに変更される可能性があります。
リダイレクトのコードとしては他にも 303、304、307、308 がありますが、これらはアプリケーションレベルでの特定のロジックに基づいて使用される（POSTリダイレクトリクエストのタイミングで使う等）なので、ALBには301と302のみが実装されています。
おわりに
簡単にですが、実際の動作確認を試しながらリダイレクトの仕様について調べてみました。
301と302は同じような動作にも見えますが、大きな違いとなります。結構調べると出てくるので、ハマるポイントでもあるのかもしれません。
以上です。ありがとうございました🙌
Discussion