問題タブ [rfc2616]

502 Bad Gateway小さなプロキシを作成しましたが、プロキシサーバー自体に内部エラーがある場合にエラーを返すのが正しいかどうか疑問に思っています。RFCは、これは相手側のサーバーが悪い応答をした場合にのみ行うことであると言っているようです。

サーバーは、ゲートウェイまたはプロキシとして機能しているときに、要求を実行しようとしてアクセスしたアップストリームサーバーから無効な応答を受信しました。

これは、たとえばアップストリームサーバーがcontent-length応答本文の長さとは異なるヘッダーを設定している502場合、つまり応答が無効な場合にエラーを設定する必要があることを意味します。

RFCを誤解していますか？

Rfc2616 には、GET と POST 以外にも、DELETE や PUT などの多くのメソッドがリストされています。ただし、html フォームのメソッド フィールドでは、GET または POST のみを指定できるようです。

GET や POST 以外のリクエスト メソッドを使用する HTML ページにリンクやフォームを作成することはできますか?

w3.org（RFC2616）は、チャンクの最大サイズを定義していないようです。ただし、最大チャンクサイズがないと、チャンク拡張用のスペースはありません。最大チャンクサイズが必要です。そうでない場合、理解できない場合はチャンク拡張を無視することはできません（引用:) "MUST ignore chunk-extension extensions they do not understand"。

POST リクエストに無効なパラメータが含まれている場合に返される適切なエラー コードは何ですか? 例: フォームはイベントのデータを受け取りますが、提供された日付は過去のものです。または、フォームがユーザー登録用のデータを受け取りますが、提供された名前は数字または無効な個人名です。

HTTP / 1.1標準であるrfc2616では、引用符で囲まれた文字列は次のように定義されています。

この定義では、「」はTEXTのように見えるため、<">\<">（quote、backslash、quote）は有効な引用符で囲まれた文字列のように見えます。ただし、これは、エスケープ文字としてのバックスラッシュの適切な使用法と矛盾し、引用符で囲まれた文字列の終わりを明確に判別できない可能性さえあります。ここで私のエラーはどこにありますか？

RFCはまた述べています

引用符で囲まれた文字列内のLWSでもSPに置き換えることができるという解釈を読みました。私がRFCを文字通りとると、それはそれが言うことです。これは、引用符で囲まれた文字列 ""、 "\ n"、 "\ n \ t \ t \ t"、…がすべて同じであることを意味するため、私はこれに戸惑っています。それらの引用符で囲まれた文字列は、実際には意味的に区別できませんか？

どちらかを使用することの違いと利点は何ですか。

対：

最初のフォームは RFC 2616 に準拠していますか?

注: json または xml などの可能性があります。

In shord：HTTP1.1標準に準拠した方法で、http：//example.com/？queryのようなURLへのGETクエリをrfc2616にどのように適用しますか？

ウィキペディアは言う

rfc2616ではそれは言う

GETリクエストに関連するのはabs_pathとabsoluteURIのみです。

abs_path

ここで、abs_pathは実際には「？」を禁止するuri rfcからのものです。これは、abs_pathが実際にはクエリ部分の前にあるuriの一部であるためです。したがって、ウィキペディアの変種は構文的に正しくないようです。

絶対URI

このためにurirfcは言います

したがって、そのようなクエリをRequest-URIに入れることは可能ですが、残念ながら、rfc2616は、プロキシと通信していないクライアントのabsoluteURIの送信を許可していません。これは、Webサーバーによって標準に準拠した方法で受信することは可能ですが、実際には、ブラウザーやその他のクライアントに準拠して標準で送信することはできません。

rel_path

驚いたことに、rfc2616は「？」と言っています。rel_pathにありますが、これはrfc2396では許可されていません。また、rel_pathルールはrfc2616のどこにも構文的に使用されていないため、httpリクエストのどこかにrel_pathを配置することはできません。

だから私の質問は、どのように標準に準拠してそのような要求を行うのか、そしてすべてのブラウザが標準を破っていますか？

私は REST アプリケーションを開発しましたが、私のアプリケーションのケースの 1 つは次のとおりです。

ユーザーはサーバー側で操作を行います。サーバーは正常にデータを受け入れますが、データベースとの通信などでエラーが発生します。エラーコードを付けて返したくない 成功コードを付けて送りたいが、エラーを示すボディがある。500、404 などのエラー コードを送信したいのですが、設計は正しいですか? また、どのステータス コードを返す必要がありますか?

HTTP 1.1 RFC を読んでいますが、次の質問に答えることができません。

次のヘッダーがあります。

これは、Rails 3 認証パーサーが「,」文字のために文字列を正しくデコードしないため、問題を引き起こしています。これは私が知っている非常に珍しいことですが、この Apache httpd 構成を使用してこれを追加します。

Apache mod_header のドキュメントには次のように書かれています。

応答ヘッダーは、同じ名前の既存のヘッダーに追加されます。新しい値が既存のヘッダーにマージされる場合、既存のヘッダーとはコンマで区切られます。これは、ヘッダーに複数の値を与える HTTP 標準の方法です。

しかし、この Authorization ヘッダーでは正しくないと思います。RFC の定義では、これは許可されていません。ただし、一部のヘッダーではカンマ区切りのリストを使用できます。これがすべての HTTP ヘッダーの一般的な規則であるかどうかはわかりません。

これが正しくないという私の考えを証明するHTTP 1.1 RFC の段落を探しています。「これは分離できるヘッダーにのみ有効です」というものをすでに見つけましたが、これは証拠ではありません。

同じフィールド名を持つ複数のメッセージ ヘッダー フィールドは、そのヘッダー フィールドのフィールド値全体がコンマ区切りのリスト [つまり、#(値)] として定義されている場合にのみ、メッセージに存在する場合があります。複数のヘッダー フィールドを 1 つの "field-name: field-value" ペアに結合することが可能でなければなりません。これは、メッセージのセマンティクスを変更することなく、後続の各フィールド値を最初のフィールド値に追加し、それぞれをコンマで区切って行います。したがって、同じフィールド名を持つヘッダー フィールドが受信される順序は、結合されたフィールド値の解釈にとって重要であり、したがって、プロキシは、メッセージが転送されるときにこれらのフィールド値の順序を変更してはなりません。

意味がわかりませんが、明確な証拠を探しています。

RFC 2616 HTTP/1.1 定義では、次の一般的な HTTP メソッドが存在すると述べています。

GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS、CONNECT

しかし、System.Web.Mvc.HttpVerbs列挙型には TRACE、OPTIONS、および CONNECT がありません。

特定の決定を下すためにリクエストから HttpVerb を取得するアクション フィルターがあるので (たとえば、リクエストがベース タイプ A のモデルを PUT している場合、データを設定します)、このユーティリティ コードは次のようになります。最後の 3 つのリクエストに対して ArgumentOutOfRangeException をスローしています (ほとんどが OPTIONS - Google 翻訳から来ているようです):

これを回避する方法がわからない - 何かアイデアはありますか?

私が考えることができる唯一のことは、最初に生のHTTPメソッドをチェックするようにすべての参照コードを変更し、次にTRACE、OPTIONS、またはCONNECTでない場合にのみユーティリティを呼び出すことです。これはちょっとハックです。

enum クラスにないのはなぜですか? それには具体的な理由がありますか？MVC は単にこれらのタイプのリクエストを処理できないのでしょうか?

OPTIONS メソッドの音からすれば、MVC に到達することさえできず、IIS 自体で処理する必要がありますか?