20

HTTPプロトコルは、長い間マルチパート応答をサポートしてきました。私は以前、適切に装備されたコンシューマーを備えたAPIにそれらを使用しましたが、それらのブラウザーサポートは非​​常に優れているようには見えず、過去50年間で改善されていません。なぜそうなるのかについて多くの情報を見つけるのに苦労しました。特にBackbone.jsのようなクライアント側フレームワークを採用しているアプリの場合、最初のリクエストでWebアプリが必要になることがわかっているすべてのアセットを送信することで、HTTPリクエストを削減できるようにしたいと思います。

ブラウザーメーカーもWebパフォーマンスエバンジェリストもこの長年のHTTP構造に注意を払っていない理由について、ホワイトペーパー、トレード記事、失敗した実験、またはその他の証拠はありますか？

完全に明確にするために、私は意見を探していませんが、これがなぜであるかを示す真の証拠を探しています。たとえば、Mozillaが数年前にこれについて何かを公開した場合、またはFirefoxのバグトラッカーにクローズドチケットがあり、リード開発者がこれを実装しない理由についてコメントしている場合です。

4

2 に答える 2

4

実際、古いバージョンのIEは、マルチパートアプリケーション/オクテットストリーム応答を処理し、ダウンロード操作中にすべてのファイルを保存しますが、これは最近削除され（IE7の時点で）、ダウンロードのみに固有のものでした。

あなたが提案したものがHTTP仕様の「精神」に沿っているとは思わないので、あなたが探している「証拠」を見つけるつもりはないと思います。それが何を意味するのかを説明しようと思います。HTTPの基本的なパラダイムは、クライアント主導の要求と、その要求に対するサーバーの応答です。しかし、クライアントがそれらをどう処理するかを知っているという前提で、サーバーが任意のファイルを返すことを提案しているようです。

ただし、クライアントが最初に複数のファイルを明示的に要求することを提案する場合は、何かに取り組むことができると思います。HTTP 1.1仕様では、Accept client-requestヘッダーでマルチパートのサポートを示すことができるため、これはHTTP設計者がこれが機能することを想定した方法のように見えます。残念ながら、仕様では、クライアントが受信する予定のファイルをどのように識別するかについては言及されていません。これは、ブラウザーやWebサイトのレンズを通してではなく、定義されているとおりにHTTPを真空で見ると理解できます。これは、解決するためにクライアントとサーバーに任されている実装の詳細です。これは、別のレイヤーに適用される懸念事項です。つまり、コンテンツを要求して転送する方法ではなく、コンテンツとは何か、コンテンツがどのように消費されるかです。

もちろん、さまざまな解決策を想像するのは簡単ですが、参照する標準がなければ、ブラウザ開発者の努力を正当化するものではないようです。マイクロソフトのような（広く採用されているサーバーとブラウザーを制御している）誰かがこれを実装していると想像できますが、彼らは仕様を発明し、人々は不平を言うでしょう。どうやら、W3Cが何かに同意するまで10年待つ方が良いと判断したようです...

于 2012-05-24T03:57:08.160 に答える
2

W3組織自体から直接（http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2）：

3.7.2マルチパートタイプ

MIMEは、いくつかの「マルチパート」タイプ（単一のメッセージ本文内の1つ以上のエンティティのカプセル化）を提供します。RFC 2046のセクション5.1.1で定義されているように、すべてのマルチパートタイプは共通の構文を共有します

[40]、メディアタイプ値の一部として境界パラメータを含める必要があります。メッセージ本文はそれ自体がプロトコル要素であるため、本文部分間の改行を表すためにCRLFのみを使用する必要があります。RFC 2046とは異なり、マルチパートメッセージのエピローグは空でなければなりません。HTTPアプリケーションはエピローグを送信してはなりません（元のマルチパートにエピローグが含まれている場合でも）。これらの制限は、マルチパートメッセージ本文の自己区切りの性質を維持するために存在します。メッセージ本文の「終了」は、終了マルチパート境界によって示されます。

一般に、HTTPはマルチパートメッセージ本文を他のメディアタイプと同じように扱います。厳密にはペイロードとして扱います。唯一の例外は、206（Partial Content）応答に表示される「multipart / byteranges」タイプ（付録19.2）です。これは、セクション13.5.4および14.16で説明されている一部のHTTPキャッシングメカニズムによって解釈されます。他のすべての場合、HTTPユーザーエージェントは、マルチパートタイプを受信したときのMIMEユーザーエージェントと同じまたは同様の動作に従う必要があります。マルチパートメッセージ本文の各本文部分内のMIMEヘッダーフィールドは、MIMEセマンティクスで定義されている以上のHTTPにとって重要ではありません。

一般に、HTTPユーザーエージェントは、マルチパートタイプを受信したときのMIMEユーザーエージェントと同じまたは同様の動作に従う必要があります。アプリケーションが認識されないマルチパートサブタイプを受け取った場合、アプリケーションはそれを「マルチパート/混合」と同等として扱わなければなりません。

  Note: The "multipart/form-data" type has been specifically defined
  for carrying form data suitable for processing via the POST
  request method, as described in RFC 1867 [15].
于 2013-06-01T19:17:59.470 に答える