HTML5のアップロード、大きなファイルソリューション

I.概要

 

いわゆるHTTPは、実際には、すでにダウンロードを継続するために開始する場所からダウンロードされたファイルをダウンロードするだけでいい。HTTPプロトコルの以前のバージョンでは、ブレークポイントをサポートしていません、HTTP / 1.1初めはサポートされています。レンジとContent-レンジエンティティヘッダをダウンロードするときにブレークポイントは、一般的に使用されます。HTTPプロトコル自体は、ブレークポイントのアップロードをサポートしていない、それは、独自の実装を必要とします。

 

二、レンジ 

 

リクエストヘッダは、最初のバイトの位置及びデータの最後のバイト、一般的なフォーマットを指定するために使用されます。

 

    範囲:クライアントは、サーバーが、ゼロからのオフセットのバイトをフィールドの変更に続いて、ダウンロードファイルのサイズの一定の期間を指定することができます要求します。典型的な形式:

    範囲:(単位=最初のバイトPOS) - [最後のバイトPOS]

    範囲:バイト= 4000- 4000バイトダウンロード第一の部分からファイルの最後まで

    範囲:バイト= 0〜Nダウンロードバイト範囲の0-N

    範囲:バイト= MN MNダウンロード最初のバイトの範囲

    範囲:バイト= -N最後のNは、ダウンロードされたコンテンツをバイト



 

1.次の点に注意する必要があります。

(1)このデータ・セクションは、開始値が0である、閉区間で、「範囲:バイト= 0-1」は、このような要求には、要求の開始バイト実際に2です。

(2)「範囲:バイト= -200」は、要求されたファイルの開始位置の201バイトを使用するのではなく、ファイルの終わりに200バイトの要求されません。

最後のバイトposは最初のバイトのposよりも小さい場合(3)は、その後、レンジ要求は無効な要求、200でレンジ要求と応答を無視するサーバーが必要で、ファイル全体がクライアントに送信されます。

(4)またはファイルの長さに等しく、その後Range要求を満たすと考えることができないよりも、最後のバイトPOS 416に応答するサーバの必要性、要求範囲充足されない場合。

 

2.例を説明します:

最初の500のバイトを表し:バイト= 0から499まで  

第500バイトを表し:バイト= 500-999  

最後の500のバイトを表します:バイト= -500  

範囲を超えて500バイト示す:バイト= 500-  

最初と最後のバイト:バイト= 0-0、-1  

いくつかの範囲を指定:バイト= 500-600,601-999 

 

三、コンテンツレンジ

 

応答頭、体全体の部分で指定された挿入位置は、彼はまた、エンティティ全体の長さを示します。サーバーのクライアント部分への応答を返し、それがスコープおよびカバレッジからの応答の全体的な物理的な長さを記述しなければなりません。一般的な形式: 

 

コンテンツ範囲:バイト(単位最初のバイトPOS) - [最後のバイトPOS] / [エンティティlegth] 

 

四、ヘッダーの例

 

ファイル全体をダウンロードするための要求: 

 

GET /test.rar HTTP / 1.1 

接続:近いです 

ホスト:116.1.219.219 

範囲:バイト= 0から801 //ファイル全体をダウンロードするための一般的な要求であるバイト= 0-またはヘッドなし

 

正常な応答 

 

HTTP / 1.1 200 OK 

コンテンツの長さ:801      

コンテンツタイプ:アプリケーション/オクテットストリーム 

コンテンツ範囲:合計ファイルサイズ:0〜800/801 // 801バイト


以下のような何かを達成するため、最も単純なHTTPのいずれか:

1. 1024Kクライアントが512Kをダウンロードされたファイルを、ダウンロードします

このセグメントを肯定する必要がある2.ネットワークの中断、クライアントの要求を再開し、そのためには、HTTPヘッダーを再開する必要があります。

範囲:バイト= 512000-

このヘッドの512Kの場所は、ファイルサーバ通知からのファイル転送を開始します

3. HTTPサーバは、ファイルの512K開始位置から送信された要求、およびHTTPヘッダの増加を受け取ります。

コンテンツレンジ:512000- / 1024000バイト

そして、この時点では、サーバーは、HTTPステータスコードが206ではなく200でなければなりません返します。

但是在实际场景中,会出现一种情况,即在终端发起续传请求时,URL对应的文件内容在服务端已经发生变化,此时续传的数据肯定是错误的。如何解决这个问题了?显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义,比如实现Last-Modified来标识文件的最后修改时间,这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头,可以使用ETag头来放置文件的唯一标识,比如文件的MD5值。

终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段,帮助服务端判别文件变化。

另外RFC2616中同时定义有一个If-Range头,终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时,通过If-Range中的内容进行校验,校验一致时返回206的续传回应,不一致时服务端则返回200回应,回应的内容为新的文件的全部数据。


相关参考链接:http://blog.ncmem.com/wordpress/2019/11/15/html5%e4%b8%8a%e4%bc%a0%e8%b6%85%e5%a4%a7%e6%96%87%e4%bb%b6%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88/

おすすめ

転載: www.cnblogs.com/songsu/p/11864579.html