An overview,
The so-called “breakpoint continuation” is simply downloading, that is, continuing the download from where the file was downloaded. Breakpoints were not supported in previous versions of HTTP, but have been since HTTP/1.1. Range and Content-range headers are typically used for breakpoint downloads. HTTP does not support breakpoint upload.
Second, the Range
Used in a request header to specify the position of the first byte and the position of the last byte in the general format:
Range: used for client-to-server requests. You can change a field to specify the size of a segment of the downloaded file and its unit. The byte offset starts from 0. Typical format:
Ranges: (unit=first byte pos)-[last byte pos]
Ranges: bytes=4000- Download from 4000th byte to the end of the file
Ranges: bytes=0~N Download the content in the 0-n byte range
Ranges: bytes= m-n Downloads the contents of the m-n byte range
Ranges: bytes= -n Downloads the last N bytes of content
1. The following points need to be noted:
(1) This data interval is a closed interval with a starting value of 0, so a request such as “Range: bytes=0-1” is actually the first 2 bytes of the request.
(2) “Range: bytes=-200”, not 201 bytes at the beginning of the file, but 200 bytes at the end of the file.
(3) If the last byte pos is less than the first byte pos, then the Range request is invalid, and the server needs to ignore the Range request and respond with a 200 to 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 unsatisfiable and the server needs to respond with 416, Requested Range not satisfiable.
2. How to Lose weight
Bytes: 0-499 Indicates the first 500 bytes
Indicates the second 500 bytes: bytes=500-999
Indicates the last 500 bytes: bytes=-500
Indicates the range after 500 bytes: bytes=500-
First and last bytes: bytes=0-0,-1
Specify several ranges: bytes=500-600,601-999
Third, the Content – Range
Used in response headers to specify the insertion position of a portion of the entire entity. It also indicates the length of the entire entity. When the server returns a partial response to the client, it must describe the response coverage and the entire entity length. General format:
Content-Range: bytes (unit first byte pos) – [last byte pos]/[entity legth]
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 requests to download the entire file are bytes=0- or use this header
General normal response
HTTP / 1.1 200 OK
Content-Length: 801
Content-Type: application/octet-stream
Content-range: bytes 0-800/801 //801: indicates the total file size
The simplest implementation of breakpoint continuation might look like this:
1. The client has downloaded a 1024 KB file, of which 512 KB has been downloaded
- The network is interrupted and the client is requesting a continuation. Therefore, the fragment that needs to be continued this time needs to be declared in the HTTP header:
Range:bytes=512000-
This header tells the server to transfer files starting at 512K of location
- The server receives a resumable request from 512K of the file and adds the following to the HTTP header:
Content-Range:bytes 512000-/1024000
The HTTP status code returned by the server should be 206, not 200.
However, in actual scenarios, the file content corresponding to the URL has been changed on the server when the terminal initiates a renewal request. In this case, the data to be renewed must be incorrect. How to solve this problem? Obviously, we need a way to identify the uniqueness of the file. There is a corresponding definition in RFC2616, such as implementing last-modified to mark the Last modification time of a file, so that you can determine whether the file has been changed when it is transmitted. RFC2616 also defines an ETag header. You can use the ETag header to place the unique identifier of the file, such as the MD5 value of the file.
An endpoint should declare an IF-match or if-Modified-since field in the HTTP header to help the server identify file changes.
In addition, RFC2616 also defines an if-range header, If the terminal is used in the continuation of if-range. The contents in the if-range can be the original ETag header received or the Last modification in last-modfied. When receiving a renewal request, the server verifies the contents of the if-range. If the verification is consistent, the server returns a reply of 206; If the verification is inconsistent, the server returns a reply of 200, which contains all the data of the new file.
Relevant reference links: blog.ncmem.com/wordpress/2… Welcome to join the group to discuss: 374992201