You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
現在、URL リダイレクト (URL redirection) を用途とする主な HTTP ステータスコードは 301, 302, 303, 307, 308 の 5 つです。 これらのステータスコードについて私のまわりのエンジニアに話を聞いてみたところ、リダイレクト処理を書こうとする都度、どのステータスコードが何だったかや、細かい仕様の違いについて調べる方が多いようです。私も常々、リダイレクト系のステータスコードは、わかりづらく、憶えにくいと感じていました。そしてこの原因は、ステータスコード定義の変遷にあると考えています。 この記事は、この「わかりづらく、憶えにくい」というストレスの軽減を目的に、ステータスコード定義の歴史について RFC からひも解いてみようという個人的な試みの記録です。 HTTP ステータスコードの歴史 まずは背景を知る上で、ステータスコードに関する RFC 策定の流
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる?POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く