9

すでに圧縮されている既存の素材 (Node を使用) から長さ不明の ZIP アーカイブをオンザフライで作成します。ZIP アーカイブでは、ファイルが保存されるだけです。ZIP は、単一のコンテナを持つためにのみ使用されます。そのため、作成された ZIP ファイルをキャッシュしても意味がありません。実際の計算は必要ありません。

これまでのところ、OK。ダウンロードの再開を許可したいので、Accept-Range、Range、および Content-Range HTTP ヘッダーについて読んでいます。ダウンロードが壊れているクライアントは、次のように制限のない範囲を要求しますRange: bytes=8000000-。

どう答えればいいですか？RFC 2616 § 14.16に従って、私の回答には Content-Range ヘッダーを含める必要があります。

byte-ranges-specifier 値 (セクション 14.35.1 を参照) とは異なり、byte-range-resp-spec は 1 つの範囲のみを指定する必要があり、範囲の最初と最後のバイトの両方の絶対バイト位置を含める必要があります。

したがって、「位置Xから始まるすべて」を送信することはできません。既知のサイズの一部のみを送信するか、事前に長さを計算して、送信された最後のバイトも指定する必要があります。どちらの考えも私の状況には都合が悪い。他に可能性はありますか？

4

2 に答える 2

1

自問自答: (1) まだ長さが不明なファイルのチャンク エンコーディング、または (2) その Content-Length (または少なくとも現在の部分のサイズ) を知っていて、ダウンロードを再開できるようにする (プログレスバーと同様に）。

私はそれを受け入れることができます-私の各ZIPファイルの長さは同じになるので、どこかに保存して、その後のダウンロードに再利用できます. HTTP プロトコルでは、不明な長さのダウンロードの再開が許可されていないことに驚いています。

于 2013-03-18T21:38:36.260 に答える
0

各パーツの Content-Range フィールドを含む「multipart/byteranges」Content-Type の応答。

理由:

  1. 「Range」ヘッダーを使用してリクエストに応答する場合、成功した部分応答は 206 HTTP ステータス コードを報告する必要があります ( 14.35.1 バイト範囲セクション) 。

  2. 206 応答は、「Content-Range」ヘッダーまたは「multipart/byteranges」Content-Type ( 10.2.7 206 Partial Content )のいずれかを示唆します。

  3. 「Content-Range」ヘッダーは、終了位置の省略を許可しないため、応答に追加できません。残りの唯一の方法は、「multipart/byteranges」Content-Type を使用することです。

于 2014-07-09T17:13:56.737 に答える