问题
What is the correct response to a GET request with the header field Range: bytes=278528- if Range is not supported?
Reading the HTTP header definitions (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) i think i should at least set: Accept-Ranges: none, but it clearly states that
Clients MAY generate byte-range requests without having received this header for the resource involved.
So, if a client requests a range, should I:
- Reply with the whole file from byte 0?
- Reply with some status error? (400/406/416/501) see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
回答1:
You may ignore it, as the spec says. To be precise:
- If you support it, you return a status code of 206 Partial Content and include the proper headers like Content-Range.
- If you don’t support it, you return a 200 OK as normal.
I have not tested this, but the spec seems pretty clear. I have seen this work — using wget or curl to resume an interrupted download will properly restart from the beginning if the server does not support the Range header.
回答2:
RFC2616 section 14.35.2 says:
A server MAY ignore the Range header.
回答3:
The possibility is check the http header and if there is a range string, parse it, parse to ranges, compute skip and take positions, open file stream from url, then, seek to skip and take 'take ' bytes, setup response of it, send response and finaly close stream. do not forget to respond with range header
do not ignore range, never when you are working on big streams.
if you are using nanohttp, i can help you out with example
回答4:
Ignoring range requests can made play content (which is huge) on airplay service or another unstable or unacceptable. I know that http is not right protokol to transfer video, but try to send video to airplay from server not accepting ranges.... Airplay uses range requests...
来源：https://stackoverflow.com/questions/6204283/http-how-should-i-respond-to-range-bytes-when-range-is-unsupported