問題タブ [http-status-code-412]

私はRESTfulデータストアを構築し、条件付きGETとPUTを活用しています。条件付きPUT中に、クライアントはリソースに前のGETからのEtagを含めることができ、現在の表現が一致しない場合、サーバーは412（前提条件失敗）のHTTPステータスコードを返します。これはAtomベースのサーバー/プロトコルであることに注意してください。

私の質問は、412ステータスを返すときに、リソースの新しい表現も含めることができますか、それともユーザーが新しいGETを発行する必要がありますか？HTTP仕様は、yesまたはnoを示していないようであり、Atom仕様も示していません（ただし、それらの例では、応答に空のエンティティ本体が示されています）。新しい表現を返さず、クライアントにそれを具体的に取得させるのはかなり無駄に思えます。考え？

データベースにアクセスする RESTful Web サービスを実装しています。データベース内のエンティティは、複数の更新を検出するためにバージョン管理されています。たとえば、現在の値が{"name":"Bill", "comment":"tinker", "version":3}の場合、1 人のユーザーが PUTを実行{"name":"Bill", "comment":"tailor", "version":3}すると、リクエストは成功し (200 OK)、新しい値は になります{"name":"Bill", "comment":"tailor", "version":4}。2 番目のユーザーが{"name":"Bill", "comment":"sailor", "version":3"}その要求を PUT すると、バージョン番号が一致しないため、失敗します (409 競合)。

既存の非 RESTful インターフェイスがあるため、データベースの設計を変更することはできません。RESTful インターフェイスは、バージョン チェックの詳細を処理する既存のインターフェイスを呼び出します。

RESTful Web サービスの経験則は、可能な限り HTTP の詳細に従うことです。この場合、リクエストで条件付きヘッダーを使用し、バージョンが一致しない場合は 412 Precondition Failed を返す方がよいでしょうか? 適切なヘッダーは If-Match のようです。このヘッダーは、リソースの現在の状態の表現のハッシュである可能性がある ETag (エンティティ タグ) を取ります。

私がこれを行った場合、ETag は外観のためのものになります。なぜなら、バージョンはまだ私がテストしている本物だからです。

「よりRESTfulにする」以外に、これを行う必要がある理由はありますか?

HTTP 412: Precondition Failed, error for a web service? を返す必要がある場合と返すべきでない場合は、私にはわかりません。データの検証時に使用することを考えています。たとえば、クライアント POST の XML データで、そのデータに必要なデータ要素が欠落している場合、412 とエラーの説明で応答します。

それは HTTP 412 で応答するという精神に沿っているのでしょうか、それとも別のものを使用する必要がありますか (別の http エラー コードや Web アプリケーションの例外など)?

「If-Match」ヘッダーを使用して PUT または DELETE を実行するとき、クライアントから送信された ETag が古さを示している場合、単に 412 を返すのではなく、最新のエンティティ全体 (そのHTTP ヘッダーに新しい ETag を追加する) ため、クライアントは別の GET ラウンド トリップを実行する必要がありません。それ以外の場合は確実に実行します。少なくとも私の使用例では、おそらく 100% のケースで実行します。

412 のドキュメントには、賛成も反対も何もありません 。

そして、たとえば、ステータス コード 409 を見ると、4xx エラーの応答本文で好きなことをすることは一般的に問題ではないようです: http://www.w3.org/Protocols/rfc2616/rfc2616 -sec10.html#sec10.4.10

では、完全な最新エンティティとその ETag を返すことに反対するもの (特に HTTP 仕様) はありますか?

だから私はRestAPIを開発しています

リソースを作成するためにPOSTが行われ、必須フィールドが欠落している場合、何を返す必要がありますか？

400不正な要求

また

412-前提条件が失敗しました

なぜ？

この問題は、Safari for Mac でのみ発生します。次のように、クリーンな json データ ファイルを読み込んでいます。

私のCORS対応サーバーには次のものがあります。

リクエストヘッダーをキャプチャしましたが、私が見る唯一の違いは次のとおりです。明確にするために、失敗したリクエストには次のものが含まれていますが、次の更新には次のものが含まれていません。したがって、Access-Control-Allow-Headers への項目の追加:

これはサーバー構成の問題ですか、jQuery の使用法ですか、それとも何か他の問題ですか? Safari が 1 回おきの更新で一貫してヘッダーを変更するのは奇妙です。

kendoPanelBar からロードされたさまざまな KendoUI グリッドを使用する localhost で実行されているサイトがあります。OSX 10.9 (Mavericks) に更新するまで、すべて正常に動作していました。$.post jquery 呼び出しを使用してグリッドを 1 回ロードできるようになりましたが、2 回目にグリッドをロードしようとすると、412 (Precondition Failed) が返されます。グリッドを再度ロードできるようにするには、キャッシュを空にする必要があります。最も奇妙な点は、これが Safari 7.0 でのみ発生していることです。Firefox 24.0 は正常に動作しており、エラーなしでグリッドをロードできます。

これは、アップロードのために変更された可能性のある私の Web サーバー構成の問題ですか、それとも...これは単に新しい Safari の問題にローカライズされているのでしょうか、それとも... Safari のコードに欠けている可能性があるものがありますか?厳密にチェックされていますか？

オブジェクトを返す API エンドポイントがありVoucherます。

バウチャーは第三者から取得されます。

有効期限など、チェック/検証する条件がいくつかあります。
そのため、クライアント アプリケーションが/voucher/1234ID 1234 のバウチャーを要求すると、サード パーティから取得されます。

有効期限が < now の場合、エラーを返す必要があります。

標準の HTTP エラーを返したい。

どれが最も適していますか？
最初は 412 だと思っていましたが、今はわかりません。

REST API を呼び出すクライアントの動作を最適化することに関心があります。この API では、特定の POST 操作でIf-None-Match: *ヘッダーを含めることができます。これにより、アップロードされているアイテムがシステムに既に存在する場合、サーバーは HTTP 412 応答を報告します。とともに使用すると、 RFC 2616 §8.2.3で説明されているように、サーバーは 100 応答を送信する代わりExpect: 100-continueに412で応答します。クライアントでこの状態を検出し、この場合はリクエストの本文を送信しないようにしたいと思います。

を直接操作する場合HttpWebRequest、これを実装するのはかなり簡単です。GetRequestStream(または)を呼び出した後GetRequestStreamAsync、結果の にデータを書き込む前Streamに、コードでプロパティをチェックする必要がありHaveResponseます。値が の場合true、リクエスト ストリームを閉じて、呼び出しに進みますGetResponseAsync。

HttpClient現在、直接作業するのではなく、使用するように移行する作業を行っていHttpWebRequestます (複数のプラットフォームでのサポートを改善するため)。現在StreamContent、リクエストの本文を表すために を使用しており、サーバーが 100 または 412 レスポンスを送信したかどうかに関係なく、ストリームのコンテンツが送信されることを観察しています。の代わりにHttpClientandを使用して、上記と同様の最適化を実行するにはどうすればよいですか?HttpRequestMessageHttpWebRequest

デバイスで UPnP イベント サブスクリプションを更新しようとすると、412 HTTP エラー: Precondition Failed, bad SID が発生します。

このエラーは 1 つのデバイスでのみ発生し、他のすべてのデバイスは正常に動作します。バギーデバイスはD-Link XTreme N GIGABIT Router DIR-655 (Firmware Version:1.34WW, 2010/09/30), H/w ver: A4.

UPNP サブスクリプション ログ (Wireshark によってキャッチ)

サブスクリプション：

リニューアル：

初めてサブスクリプションの有効期限が切れる 5 秒前、たとえば最初のサブスクリプションから 55 秒後にサブスクリプションを更新しようとしました。2 回目の試行: 45 秒目ですが、結果は同じです。

また、サブスクリプション要求で HTTP/1.1 を使用しようとしました (そして "Connection:close" ヘッダーを追加しました) が、効果はありません。

私が間違っていることは何ですか？

UPD1 フォームウェアを 1.37WW に更新しても何も変わらない

UPD2

購読直後に購読を更新しようとすると、うまくいきます。750 ミリ秒待ってから更新 - 動作します。900 ミリ秒待ってから更新 - HTTP 412 で失敗します。D-Link 機器にバグがあるようです (別の D-Link ルーター DI-624 も同様に動作します)。インテル デバイス バリデーター ( https://software.intel.com/en-us/articles/intel-tools-for-upnp-technologies ) は、DIR-655 および DI-624 イベントをエラーなしで検証しますが、購読と更新のステップの間で一時停止します。したがって、UPNP イベンティングは信頼できるメカニズムではなく、使用しない方がよいと思います。

このようなデバイスの動作は、upnp イベント メカニズムのアイデアを危うくします。