400 Bad Requestとは
通常、クライアント側からのリクエストが不正な場合に返されます。原因は多岐に渡りますので、サーバーログやデバッグツールなどを利用しないとトラッキングが難しいものもあります。
今回は、その中でも特に遭遇することの多い、Cookieやキャッシュが起因の対処方法についてまとめてみます。そのほかの原因は、むしろサーバー側で故意に実装されているものが多く、対処が不可能なものが多いので、割愛します。
訪問者側の対策
原因
400 Bad Requestは、WebサイトやWebアプリケーションのバージョンアップが原因で起こることがあります。これは、バージョンアップのときにCookieやキャッシュの情報が古いまま残っているため、サーバーが古い情報を不正な情報とみなしてしまうことから起こります。
対策
キャッシュのクリア
次のサイトを参考に、Cookieとキャッシュをクリアします。
- Chrome 閲覧データを削除する
- Firefox Firefox のキャッシュを消去するには
- Edge Microsoft Edge の閲覧履歴を表示または削除する
- Internet Explorer Cookie の削除と管理を行う
訪問者の情報が原因の場合は、この手順で解決できます。
プラグイン（拡張機能）を無効にする
稀にですが、requestの内容を改変したり、Cookieを書き換えたりするプラグインが存在することがあります。上記で解決しない場合は、ブラウザのプラグインを無効化してみましょう。
- Chrome 拡張機能をインストールする、管理する
- Firefox アドオンの無効化または削除
- Edge Adding, moving, and removing extensions for Microsoft Edge
- Internet Explorer Internet Explorer 11 のアドオンを管理する
ブラウザを変えてみる
たいていの場合、Chrome、Firefox、Safariあたりの主要ブラウザはサポートされているはずですが、稀に利用しているブラウザのサポートがされていないWebサイトがあります。
こういった場合、ブラウザを変えて複数試してみることは有力な手段です。
解決できない場合
この段階で、ユーザー側にできることはありませんので、回復するまで待つか、サイトの管理者に連絡しましょう。
開発者側の対策
ウェブサイトのバージョンアップを行ったときに、このような問題に直面したことはありませんか？また、ユーザーに向けて上記で挙げたような案内をしていないでしょうか。
これらは、本来訪問者の手を煩わせることなく、開発者側で対策すべきことですから、当然Cookieの管理も開発者側で行う必要があります。
Cookie対策
そもそも、エラーが起こるほどのCookieを設定してはいけません。たとえば、ECサイトなどにおけるカート内の情報は、キャッシュやKVSなどを用いてサーバー側で保持したり、WebStorageなどのローカルDBに保存しておくべき情報です。
しかし、全てをそういった構成にするには適さないケースもあります。その場合の対策を考えてみましょう。
Cookieの有効期限を設定する
たとえば、Cookieの有効期限を短い時間にすることはこの場合有効でしょう。たとえば、セッションを含む全てのCookieを30分以内とすることで、Cookie起因のバグが起こったとしても30分経過すれば正常に動作するようになります。
Bad Request専用ページを作っておく
Bad Requestが発生したら、対象のクッキーを削除するJavaScript、またはサーバープログラムを仕込んだページに飛ばすように設定します。NginxやApacheをはじめ、大抵のHTTPサーバーは、エラーページをカスタマイズすることができます。Set-CookieヘッダをHTTPサーバーで設定しても構いません。
サードパーティJavaScriptなどを精査する
サードパーティ製のJavaScriptの中には、Cookieの内容を書き換えるものも存在します。”cookie”などの文言で検索して内容を精査することも場合によっては有効かもしれません。
キャッシュ対策
バージョンアップ時に、ブラウザキャッシュがユーザーのブラウザに残ってしまい、サイトが正常に動かなくなったり、意図しない問題が起こったりします。
Cache Busting
ポピュラーな対策が、Cache Bustingと呼ばれる、クエリ文字列をリソースの末尾に加えてロードする方法です。こうすることによって、ブラウザに「別のリソース」と認識させて、キャッシュを効かなくすることができます。
<link rel="stylesheet" href="style.css?version=1">
主に利用されるのは、アプリケーションのバージョンや更新日時、ハッシュなどです。gruntなどでreplaceしたり、サーバー側のレンダリングで埋め込んだりできます。
リクエストサイズなどの制限
tomcat、jettyほか、主要なサーバーでは、リクエストヘッダなどに制限を課すことができるものがあります。ある一定のリクエストサイズを超えたら400が返ってくる、という場合には、この辺の設定を見直すとよいかもしれません。
まとめ
Bad Requestが出た場合に試すべきことを思いつく限り書いてみました。特に開発側は、このような再現性に乏しいエラーに対応することは辟易としますが、ユーザーに手間をかけさせずに利便性を高めていきたいものですね。