I. Overview
The so-called resumable downloading actually only refers to downloading, that is, to continue downloading from the place where the file has been downloaded. In the previous version of the HTTP protocol, breakpoints were not supported. HTTP/1.1 has been supported since. The Range and Content-Range entity headers are generally used when downloading with a breakpoint. The HTTP protocol itself does not support breakpoint upload, you need to implement it yourself.
Two, Range
Used in the request header to specify the position of the first byte and the position of the last byte, the general format:
Range: Used for requests from client to server. You can specify the size and unit of a certain section of the downloaded file by changing the field. The byte offset starts from 0. Typical format:
Ranges: (unit=first byte pos)-[last byte pos]
Ranges: bytes=4000- download from the 4000th byte to the end of the file
Ranges: bytes=0~N download the contents of the 0-N byte range
Ranges: bytes=MN Download the contents of the M-Nth byte range
Ranges: bytes=-N download the last N bytes of content
1. The following points need to be noted:
(1) This data interval is a closed interval, and the starting value is 0, so a request such as "Range: bytes=0-1" is actually 2 bytes at the beginning of the request.
(2) "Range: bytes=-200", it does not indicate the 201 bytes at the beginning of the requested file, but indicates the 200 bytes at the end of the requested file.
(3) If the last byte pos is less than the first byte pos, then the Range request is an invalid request. The server needs to ignore the Range request, and then respond with a 200, and send the entire file to the client.
(4) If the last byte pos is greater than or equal to the file length, then the Range request is considered unsatisfied, and the server needs to respond with a 416, Requested range not satisfiable.
2. Example explanation:
Represents the first 500 bytes: bytes=0-499
Represents the second 500 bytes: bytes=500-999
Represents the last 500 bytes: bytes=-500
Indicates the range after 500 bytes: bytes=500-
The first and last byte: bytes=0-0,-1
Specify several ranges at the same time: bytes=500-600,601-999
Three, Content-Range
Used in the response header to specify the insertion position of a part of the entire entity, and it also indicates the length of the entire entity. When the server returns a partial response to the client, it must describe the scope of the response and the length of the entire entity. General format:
Content-Range: bytes (unit first byte pos) - [last byte pos]/[entity legth]
Four, Header example
Request to download the entire file:
GET /test.rar HTTP/1.1
Connection: close
Host: 116.1.219.219
Range: bytes=0-801 //Generally request to download the entire file is bytes=0- or not use this header
Normal response
HTTP/1.1 200 OK
Content-Length: 801
Content-Type: application/octet-stream
Content-Range: bytes 0-800/801 //801: total file size
One of the simplest implementations of resumable transfer is as follows:
1. The client downloads a 1024K file, of which 512K has been downloaded
2. The network is interrupted and the client requests resuming, so it is necessary to declare the fragments that need to be resumed in the HTTP header:
Range:bytes=512000-
This header informs the server to start transferring the file from the 512K position of the file
3. The server receives the request for resuming the transfer with a breakpoint, and starts the transfer from the 512K position of the file, and adds in the HTTP header:
Content-Range:bytes 512000-/1024000
And at this time, the HTTP status code returned by the server should be 206 instead of 200.
However, in an actual scenario, a situation may arise, that is, when the terminal initiates a resuming request, the file content corresponding to the URL has changed on the server side, and the resuming data must be wrong at this time. How to solve this problem? Obviously we need a way to identify the uniqueness of the file at this time. There are also corresponding definitions in RFC2616, such as implementing Last-Modified to identify the last modification time of the file, so that it can be judged whether the file has been modified when the file is resumed. At the same time, RFC2616 also defines an ETag header, which can be used to place the unique identifier of the file, such as the MD5 value of the file.
The terminal should declare the If-Match or If-Modified-Since field in the HTTP header when initiating the resuming request to help the server identify the file change.
In addition, RFC2616 defines an If-Range header at the same time, and the terminal uses If-Range to resume transmission. The content in If-Range can be the first received ETag header or the last modification time in Last-Modfied. When the server receives the resuming request, it will verify the content in the If-Range. If the verification is consistent, it will return a 206 resuming response. If it is inconsistent, the server will return a 200 response. The content of the response is all of the new file. data.
Related reference links: http://blog.ncmem.com/wordpress/2019/08/09/http%e6%96%ad%e7%82%b9%e7%bb%ad%e4%bc%a0/
welcome Group discussion: 374992201