All geek questions in one place

Does an HTTP resource that accepts range requests always indicate the length of the content?

Before starting a range request, I first check to see if it is supported with a HEAD request. I usually return something like this:

curl -X HEAD -i http://bits.wikimedia.org/images/wikimedia-button.png HTTP/1.1 200 OK ... Content-Length: 2426 Accept-Ranges: bytes ...

Is Content-Length guaranteed by the HTTP / 1.1 specification in this case? I cannot find the final answer, but it seems that I need to know the Content-Length before I make a range request.

+6
source share
1 answer

No.

According to any other answer with a status code of 200, such an answer SHOULD (in the sense of RFC 2119 “ SHOULD ”, which can be summarized as “better to hell, why not, and be able to say what the hell”) include the length ( RFC 2616 §14.13), several scenarios in which it is prohibited (§4.4) (in particular, the value must be both an entity and a transmission length, and as such are only valid when the transmission encoding is an "identifier" [default]) . There is no reason why the Accept-Ranges header does not need to be sent along with encoded and / or compressed transmission encoding. (Unlike compressed encoding content, in this case range , for example content-length refers to the compressed size).

Some things worth noting:

  • The server can always ignore the range request and respond with the full length, even if it suggested otherwise. (§14.35.2) Therefore, you should always be prepared to accept this.
  • The server can read range or If-Range , even if it does not indicate that it will be through Accept-Ranges . (§ 14.5)
  • A valid range may be, for example, 123- means "send me everything from octet 123 to the end" (§14.35.1)
  • A range , for example. 123-500 is valid even if the size of the object is less than 500, in which case as many octets as available should be sent. However, this would not be true if there were only 123 octets in all essence. (§14.35.1)
  • Values ​​other than bytes are valid, but undefined for Accept-Range . (§3.12) This means that the server is doing something non-standard, so if bytes is not mentioned, you should interpret it as not including Accept-Range .
  • Although content-length is not included in the response, including Accept-Range , this is not very likely. As a rule, if you looked at such answers as if they did not include the Accept-Range header, then you would be safe from the wrong steps in the face of such behavior, while at the same time using the range of behavior, most of the time when it has come.
+5
source

Source: https://habr.com/ru/post/978555/

More articles:


All Articles