ユーザーが送信したデータを処理する処理ファイルがありますが、その前に、クライアントからの入力を予想される値と比較して、クライアント側のデータが変更されないことを確認します。
HTTP ステータス コードについてはあまり詳しくありませんが、それについていくつか調査し、予期しない入力の処理に最適なものを選択しました。そこで、次のコードにたどり着きました。
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
今のところ、どちらを使用すればよいのかよくわかりません。400 Bad Request がよく使用されているのを見てきましたが、説明からわかるのは、エラーは不正な入力ではなく、存在しないリクエストによるものだということです。
一方、417 Expectation Failed は私の用途にぴったりのようですが、これまでこのヘッダー ステータスを見たことも実験したこともありません。
あなたの経験と意見が必要です、どうもありがとうございます!
フォーム/プロセスページのドラフトと私の実験の詳細については、以下をご覧ください。このリンク。
追加: 私がこれを必要とするもう 1 つの理由は、Google による操作を防ぐためです。これはバックエンドで使用されるだけでなく、ゲスト/ユーザーのインタラクションが表示され、ページのコンテンツが表示されるフロントエンドでも使用されます。
200 OK または 403 Forbidden ステータス コードを返すことは、存在するページ、または存在が許可されているページに対して有効であると私は信じています*。
*追加 2: 417 と 100 を調べたところ、ここで私がやろうとしていること (少なくともアップロード処理の場合のみ) と似ていることがわかりました。 http://benramsey.com/blog/2008/04/http-status-100-continue/
- 例:*Xサイトにリンクしているウェブページhttp://www.example.com/page.php?query=lol&query2=failHTTP ヘッダーが OK と指定されているため、Google によってインデックスされます。
私がたどり着いた解決策:
確かに、404 が再び表示される可能性があります。HTTP がそれを提供しているのであれば、それとは異なる解決策が欲しかったのですが、今のところ、404 が依然としてこの目的に使用できる最善の解決策のようです。皆さん、ありがとうございます。私の質問に対する答えが見つかりました。
答え1
GET リクエストのパラメータが正しくない場合、標準的な対処法は 404 (見つかりません) または 200 (OK) のいずれかを返すことです。
GET リクエストを使用する RESTful な方法は、リソースを照会する (何かを取得する) ことです。したがって、必要なパラメータが既存のリソースに対応していない場合 (不完全であるため)、URI で照会されたリソースが見つからないと正確に言うことができます。
実際には、ブラウザーが 404 ページを無視して独自のページに置き換えるような事態を避けたい場合 (IE 9 と 10 の場合)、200 を使用することをお勧めします。アプリケーションをリソースと考える場合は、200 が適切です。アプリケーションにクエリを実行し、結果が返されます (たまたまエラーでしたが、HTTP レベルではありませんでした)。ただし、この使用法はあまり RESTful ではありません。
答え2
この417エラーは、サーバーが満たすことのできない HTTP ヘッダーをクライアントが送信した場合にのみ発生しますExpect。これは、リクエスト内のアプリケーションの「予期される入力」とはまったく関係がありません。使用しないでください。
一方、400エラーは、サーバーが理解できない不正な構文が HTTP リクエストに含まれている場合にのみ送信されます。
どちらもアプリケーション ロジックの検証失敗には適していませんが、400少しは適切だと思います。
403Stack Overflow での質問で使用することを検討していたエラーは、私の意見では最善の選択肢です。
予期した値が $_GET に見つからなかったときに 403 Forbidden ヘッダーを使用しましたが、よく考えてみると、これは実際にはログインを必要とするアクションではなく (もちろん、ユーザーは管理パネルを表示するためにログインする必要があります)、予期しない値の入力のようなものです。
あなたが考えているのは401、認証が必要な場合に使用される応答コードです。 403は、リクエストの一般的な拒否であり、まさにあなたが望んでいるもののように思えます。
これはすべて、応答コードを返すことを前提としています。これは API の場合は理にかなっています。ただし、ユーザー向けの HTML ページの場合は、本文にエラー情報を含んだ4xxを送信する可能性が高くなります。200
答え3
何をしているのかよく分かりませんが、考慮していない可能性のある追加のオプションがあります - 200 - OK。 理由は、データを正しく受信したためです。問題は、それがアプリケーションに対して有効ではないことです。これは、実際には HTTP プロトコルの問題ではありません。
ここで関連するRFCはRFC2616 の翻訳400を使用することもできますが、その場合はクライアントにRFCからデータを変更する機能を提供する必要があります。
10.4.1 400 不正なリクエスト
構文が不正なため、サーバーはリクエストを理解できませんでした。クライアントはリクエストを変更せずに繰り返すべきではありません。
417に関してRFCでは次のように述べている。
10.4.18 417 期待に応えられなかった
Expect 要求ヘッダー フィールド (セクション 14.20 を参照) で指定された期待をこのサーバーが満たすことができませんでした。または、サーバーがプロキシである場合、サーバーは、要求が次のホップ サーバーによって満たすことができなかったという明確な証拠を持っています。
したがって、expect ヘッダーを使用していない場合は、この応答を使用しないでください。