[MPlayer-dev-eng] [PATCH] Fix interpretation of Accept-Ranges http header to match the RFC

[The Wanderer]

Alexander Kanavin wrote:

> Hi,
> 
> currently mplayer determines if a http stream is seekable by looking
> at the presence of "Accept-Ranges: bytes" header. If it's there,
> mplayer decides it's possible to seek by using "Range" requests, and
> not possible otherwise.
> 
> However, HTTP specification sets a different rule:
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)
> ==============================
>        Origin servers that accept byte-range requests MAY send
> 
>            Accept-Ranges: bytes
> 
>        but are not required to do so. Clients MAY generate byte-range
>        requests without having received this header for the resource
>        involved. Range units are defined in section 3.12.
> 
>        Servers that do not accept any kind of range request for a
>        resource MAY send
> 
>            Accept-Ranges: none
> 
>        to advise the client not to attempt a range request.
> ========================
> 
> So it's possible to seek in the absence of such header, and only
> "Accept-Ranges: none" disables it. Attached patch makes mplayer
> behaviour match the RFC.

By my reading of the above text, the situation is actually ambiguous,
because of the three different uses of "MAY" without any uses of "MUST".

If there is an Accept-Ranges header present with the value "bytes", then
the server is stating that it does accept such requests. However, the
server is permitted to accept such requests without providing the
header.

If there is an Accept-Ranges header present with the value "none", then
the server is stating that it does not accept such requests. However,
the server is permitted to refuse such requests without providing the
header.

Therefore, it is not possible to conclude from the absence of the header
either that the server does accept such requests or that it does not.

Assuming that it does not, as you indicate MPlayer currently does, seems
to me to be the less potentially problematic of the two possible
approaches; it means not trying to seek some of the time when it would
succeed, but the alternative would be to try to seek some of the time
when it will fail.

My word has no decisive weight here, except sometimes in matters of
grammar and spelling, but the above is my reading of the situation.


Also, for reference: patches for inclusion should be made from the root
of the source tree using 'svn diff' (and thus against the live
repository), not from outside the source tree against a local copy.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.