An overview,
A breakpoint is simply a download, which means to continue downloading a file from where it has already been downloaded. Breakpoints were not supported in previous versions of the HTTP protocol, and HTTP/1.1 has been since. The Range and content-Range headers are usually used for breakpoints. HTTP protocol itself does not support breakpoint upload, you need to implement their own.
Second, the Range
Used in the request header to specify the position of the first byte and the position of the last byte, in general format:
Range: For client-to-server requests, you can change a field to specify the size and unit of a download file. Byte offset starts at 0. Typical format:
Ranges: (unit=first byte Pos)-[last byte Pos]
Ranges: Bytes =4000- Download from the beginning of byte 4000 to the end of file
Ranges: Bytes =0~N to download contents in the 0-n byte range
Ranges: Bytes = M-n to download contents in the M-n byte range
Ranges: Bytes = -n to download the last N-byte content
1. The following points should be noted:
(1) The data interval is a closed interval with a starting value of 0, so a request like “Range: Bytes =0-1” is actually two bytes at the beginning of the request.
(2) “Range: Bytes =-200”, which does not represent the 201 bytes at the beginning of the request file, but the 200 bytes at the end of the request file.
(3) If the last Byte POS is less than the first Byte POS, then the Range request is invalid. The server needs to ignore the Range request, then respond with a 200, and send the entire file to the client.
(4) If the last Byte POS was greater than or equal to the file length, then the Range request was considered unsatisfiable and the server needed to respond to a 416, Requested Range not Satisfiable.
2. Example explanation:
Bytes =0-499 bytes
Bytes =500-999 bytes
Bytes =-500 bytes
Bytes =500- = range after 500 bytes
First and last bytes: Bytes =0-0,-1
Also specify a range: Bytes =500-600,601-999
Third, the Content – Range
Used in the response header to specify the insertion location of a portion of the entire entity, which also indicates the length of the entire entity. Before the server returns a partial response to the client, it must describe the extent of the response coverage and the entire entity length. General format:
Content-range: Bytes (Unit first Byte pos) – [Last Byte pos]/[Entity Legth]
4. Header examples
Request to download the entire file:
GET/test. Rar HTTP/1.1
Connection: close
Host: 116.1.219.219
Range: Bytes =0-801 // Bytes =0- Or don’t use this header
General normal response
HTTP/1.1 200 OK
The Content – Length: 801
The content-type: application/octet stream
Content-range: Bytes 0-800/801 //801: Total file size
The simplest breakpoint continuation implementation is as follows:
1. The client has downloaded a 1024K file, of which 512K has been downloaded
2. The network is interrupted, and the client requests the continuation of transmission. Therefore, it is necessary to declare the fragment to be continued this time in the HTTP header:
Range:bytes=512000-
This header tells the server to transfer the file from the 512K location of the file
3. The server receives the breakpoint to continue the transmission request, starting from the 512K position of the file, and adds in the HTTP header:
Content-Range:bytes 512000-/1024000
And the server should return an HTTP status code of 206 instead of 200.
However, in a real scenario, the content of the file corresponding to the URL has changed at the server side when the terminal initiates the continuation request, and the data of the continuation is definitely wrong. How to solve this problem?Obviously at this point we need a way to identify the uniqueness of the file. There is also a definition in RFC2616, such as last-modified to indicate the Last modification time of a file, so that you can determine whether any changes have been made during the continuation of the file. Also defined in RFC2616 is an ETag header that can be used to place a unique identifier for a file, such as the MD5 value of the file.
When a terminal initiates a continuation request, it should declare the IF-match or IF-modified-since fields in the HTTP header to help the server identify file changes.
In addition, there is also an IF-range header defined in RFC2616. If the terminal USES iF-range in continuation. The content in the IF-range can be the first ETag header received or the Last modification in the Last-ModFIED. When the server receives the continuation request, it verifies through the contents in the IF-range. If the verification is consistent, it returns the continuation reply of 206; If not, it returns 200. The content of the reply is all the data of the new file.
the relevant reference links: http://blog.ncmem.com/wordpress/2019/08/09/http%e6%96%ad%e7%82%b9%e7%bb%ad%e4%bc%a0/
welcome into the group to discuss: 374992201
A breakpoint is simply a download, which means to continue downloading a file from where it has already been downloaded. Breakpoints were not supported in previous versions of the HTTP protocol, and HTTP/1.1 has been since. The Range and content-Range headers are usually used for breakpoints. HTTP protocol itself does not support breakpoint upload, you need to implement their own.
Second, the Range
Used in the request header to specify the position of the first byte and the position of the last byte, in general format:
Range: For client-to-server requests, you can change a field to specify the size and unit of a download file. Byte offset starts at 0. Typical format:
Ranges: (unit=first byte Pos)-[last byte Pos]
Ranges: Bytes =4000- Download from the beginning of byte 4000 to the end of file
Ranges: Bytes =0~N to download contents in the 0-n byte range
Ranges: Bytes = M-n to download contents in the M-n byte range
Ranges: Bytes = -n to download the last N-byte content
1. The following points should be noted:
(1) The data interval is a closed interval with a starting value of 0, so a request like “Range: Bytes =0-1” is actually two bytes at the beginning of the request.
(2) “Range: Bytes =-200”, which does not represent the 201 bytes at the beginning of the request file, but the 200 bytes at the end of the request file.
(3) If the last Byte POS is less than the first Byte POS, then the Range request is invalid. The server needs to ignore the Range request, then respond with a 200, and send the entire file to the client.
(4) If the last Byte POS was greater than or equal to the file length, then the Range request was considered unsatisfiable and the server needed to respond to a 416, Requested Range not Satisfiable.
2. Example explanation:
Bytes =0-499 bytes
Bytes =500-999 bytes
Bytes =-500 bytes
Bytes =500- = range after 500 bytes
First and last bytes: Bytes =0-0,-1
Also specify a range: Bytes =500-600,601-999
Third, the Content – Range
Used in the response header to specify the insertion location of a portion of the entire entity, which also indicates the length of the entire entity. Before the server returns a partial response to the client, it must describe the extent of the response coverage and the entire entity length. General format:
Content-range: Bytes (Unit first Byte pos) – [Last Byte pos]/[Entity Legth]
4. Header examples
Request to download the entire file:
GET/test. Rar HTTP/1.1
Connection: close
Host: 116.1.219.219
Range: Bytes =0-801 // Bytes =0- Or don’t use this header
General normal response
HTTP/1.1 200 OK
The Content – Length: 801
The content-type: application/octet stream
Content-range: Bytes 0-800/801 //801: Total file size
The simplest breakpoint continuation implementation is as follows:
1. The client has downloaded a 1024K file, of which 512K has been downloaded
2. The network is interrupted, and the client requests the continuation of transmission. Therefore, it is necessary to declare the fragment to be continued this time in the HTTP header:
Range:bytes=512000-
This header tells the server to transfer the file from the 512K location of the file
3. The server receives the breakpoint to continue the transmission request, starting from the 512K position of the file, and adds in the HTTP header:
Content-Range:bytes 512000-/1024000
And the server should return an HTTP status code of 206 instead of 200.
However, in a real scenario, the content of the file corresponding to the URL has changed at the server side when the terminal initiates the continuation request, and the data of the continuation is definitely wrong. How to solve this problem?Obviously at this point we need a way to identify the uniqueness of the file. There is also a definition in RFC2616, such as last-modified to indicate the Last modification time of a file, so that you can determine whether any changes have been made during the continuation of the file. Also defined in RFC2616 is an ETag header that can be used to place a unique identifier for a file, such as the MD5 value of the file.
When a terminal initiates a continuation request, it should declare the IF-match or IF-modified-since fields in the HTTP header to help the server identify file changes.
In addition, there is also an IF-range header defined in RFC2616. If the terminal USES iF-range in continuation. The content in the IF-range can be the first ETag header received or the Last modification in the Last-ModFIED. When the server receives the continuation request, it verifies through the contents in the IF-range. If the verification is consistent, it returns the continuation reply of 206; If not, it returns 200. The content of the reply is all the data of the new file.
the relevant reference links: http://blog.ncmem.com/wordpress/2019/08/09/http%e6%96%ad%e7%82%b9%e7%bb%ad%e4%bc%a0/
welcome into the group to discuss: 374992201