問題タブ [rfc2616]

rfc2616 (HTTP/1.1):

multipart/byteranges メディア タイプを使用して、単一範囲のリクエストへの応答を送信してはなりません。

結果が単一の範囲である複数の範囲の要求への応答は、1 つの部分を持つ multipart/byteranges メディア タイプとして送信される場合があります。

multipart/byteranges メッセージをデコードできないクライアントは、単一のリクエストで複数のバイト範囲を要求してはなりません (MUST NOT)。

私がこれを正しく理解していれば、1 つのリクエストで複数の範囲が multipart/byteranges を使用してもよく、クライアントはそれをデコードできなければならず、まったくリクエストしてはいけません。

「MAY」は、使用できる multipart/byteranges の代替手段もあるということを意味していますか? 存在しますか？もしそうなら、それらを要求するヘッダーはありますか?

たとえば、サーバーはすべてのバイト範囲を 1 つの部分の応答に連結する可能性がありますか?

206 個の部分リクエストをサポートするモジュールを実装しています。RFC rfc2616 を読んだ後、複数範囲のリクエストを受信したときに、「ab、ad」などの範囲の重複が許可されていないことに気付きました。

私の質問は：

単一範囲リクエストとオーバーラップ バイトはどうなりますか?

2 番目のリクエストでバイト ab を無視する必要がありますか?

また

バイトを上書きする必要がありますか?

ありがとう

API を RESTful にバージョン管理するさまざまな方法を検討していますが、主要な候補が 3 つあります。を使用することにほとんど落ち着いたと思いますX-API-Version。その議論はさておき、そのヘッダーと一般的なカスタム ヘッダーの使用に対する議論の 1 つは、ヘッダーがプロキシ サーバーによっていつ操作されるかを制御できないということです。インターネット全体で発生した場合、イントラネットやサーバー クラスターで使用された場合、またはその他の状況で発生した場合など、実際にどのような例があるか興味があります。

HTTP 仕様 (RFC-2616)のセクション 14.28 では、If-Unmodified-Since ヘッダーは HTTP サーバーによって認識されなければならず、精度は 1 秒しかないと述べられています。

リソースが 1 秒間に 1 回以上変更される場合、サーバーはこのヘッダーをどのように処理する必要がありますか?

私の理解では、サーバーは、クライアントの状態のバージョンを認識できないため、If-Unmodified-Since ヘッダーを使用したリクエストに対して「412 Precondition Failed」で応答する必要があります。それとも、サーバーは問題を無視して、クライアントが何をしているかを知っていると想定する必要がありますか?

リクエストを含む HTTP REST API を実装しています/feed。リクエストは、ユーザーのニュース フィードを返します。

リクエストには、 、userIdフォロワーのリスト、startTimeなどのいくつかのパラメータが含まれていますmaxItems。

サーバー側 (Python と Flask) で実装する最も簡単な方法は、引数を読み取ることができる JSON ペイロードを追加することです。

GET残念ながら、リクエストにペイロードを追加することはお勧めできません。多くのクライアント ライブラリではサポートされていません。

私のオプション:

• リクエストを作成/feedしPOSTます。POSTサーバーから情報を要求するために使用されるべきではないため、醜いです。
• ( ) と( ) への/feed呼び出しを分割します。通話が終わってからしか通話できないので時間の無駄です。/updateFollowersPOST/feedGETGETPOST

どちらのオプションも間違っているようです。GET一連の複雑な引数を使用して -like 呼び出しを行う標準的な方法はありますか?

RFC2616 を読んでいるときに、チャンク エンコーディング用の TE および Transfer Encoding ヘッダーに出くわしました。これらについて次の質問があります。

1. TE ヘッダーが存在するために HTTP サーバーが要求を拒否する場合、RFC に準拠していますか?
2. HTTP クライアントが TE ヘッダーと t-codings および q 値のリストを含む要求を送信し、そのような q 値が 1 になると、HTTP サーバーがそのエンコーディングで応答データを送信することが必須になります。 =0.5 gzip;q=1 (これは、エンティティ データを gzip で圧縮して送信することをサーバーに義務付けますか、それともサーバーはそれを無視して通常の方法でデータを送信できますか?)
3. HTTP サーバーがチャンク データの受信をサポートしていない場合 (RFC に違反していることは承知していますが、意図されています)、クライアントが次回 PUT を送信しないように、クライアントに送り返す正しいエラー応答コードは何でしょうか。チャンク方式で要求します。

貴重な情報と回答をお寄せいただきありがとうございます。