Class ContentRange
- All Implemented Interfaces:
- Serializable,- Cloneable,- Header,- NameValuePair
Where in a full body message this partial message belongs.
Example
Content-Range: bytes 21010-47021/47022
RFC2616 Specification
The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Range units are defined in section 3.12.Content-Range = "Content-Range" ":" content-range-spec content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" ) byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*" instance-length = 1*DIGIT
The header SHOULD indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*" character means that the instance-length is unknown at the time when the response was generated.
Unlike byte-ranges-specifier values (see section 14.35.1), a byte- range-resp-spec MUST only specify one range, and MUST contain absolute byte positions for both the first and last byte of the range.
A byte-content-range-spec with a byte-range-resp-spec whose last- byte-pos value is less than its first-byte-pos value, or whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range- spec MUST ignore it and any content transferred along with it.
A server sending a response with status code 416 (Requested range not satisfiable) SHOULD include a Content-Range field with a byte-range- resp-spec of "*". The instance-length specifies the current length of the selected resource. A response with status code 206 (Partial Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*".
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
The first 500 bytes: bytes 0-499/1234 The second 500 bytes: bytes 500-999/1234 All except for the first 500 bytes: bytes 500-1233/1234 The last 500 bytes: bytes 734-1233/1234
When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example:
HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges" as defined in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
A response to a request for a single range MUST NOT be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, MAY be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message MUST NOT ask for multiple byte-ranges in a single request.
When a client requests multiple byte-ranges in one request, the server SHOULD return them in the order that they appeared in the request.
If the server ignores a byte-range-spec because it is syntactically invalid, the server SHOULD treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing the full entity).
If the server receives a request (other than one including an If- Range request-header field) with an unsatisfiable Range request- header field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected resource), it SHOULD return a response code of 416 (Requested range not satisfiable) (section 10.4.17).
Note: clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for an unsatisfiable Range request-header, since not all servers implement this request-header.
See Also:
- 
Constructor SummaryConstructorsConstructorDescriptionContentRange(String value) Constructor.ContentRange(Supplier<String> value) Constructor with delayed value.
- 
Method SummaryModifier and TypeMethodDescriptionstatic ContentRangeStatic creator.static ContentRangeStatic creator with delayed value.Methods inherited from class org.apache.juneau.http.header.BasicStringHeaderassertString, asString, getValue, of, of, ofPair, orElseMethods inherited from class org.apache.juneau.http.header.BasicHeaderassertName, assertStringValue, equals, equalsIgnoreCase, get, getElements, getName, hashCode, isNotEmpty, isPresent, of, of, toString
- 
Constructor Details- 
ContentRangeConstructor.- Parameters:
- value- The header value.
 Can be- null .
 
- 
ContentRangeConstructor with delayed value.Header value is re-evaluated on each call to BasicStringHeader.getValue().- Parameters:
- value- The supplier of the header value.
 Can be- null .
 
 
- 
- 
Method Details- 
ofStatic creator.- Parameters:
- value- The header value.
 Can be- null .
- Returns:
- A new header bean, or null if the value isnull .
 
- 
ofStatic creator with delayed value.Header value is re-evaluated on each call to BasicStringHeader.getValue().- Parameters:
- value- The supplier of the header value.
 Can be- null .
- Returns:
- A new header bean, or null if the value isnull .
 
 
-