Hi opusfile developers, Recently, when I use the opusfile library to seek a file that located on our http server. The API reported that it was not seekable. I found that it was because of the library send http/1.0 request by default as below in http.c: op_http_stream_open when I dig a little deeper. /*Send HTTP/1.0 by default for maximum compatibility (so we don't have to re-try if HTTP/1.1 fails, though it shouldn't, even for a 1.0 server). This means we aren't conditionally compliant with RFC 2145, because we violate the requirement that "An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant...". According to RFC 2145, that means we can't claim any compliance with any IETF HTTP specification.*/ ret|=op_sb_append(&_stream->request," HTTP/1.1\r\n",11); /*Remember where this is so we can upgrade to HTTP/1.1 if the server supports it.*/ It was OK after I changed this to http/1.1 and tried again. As far as I known, the “Accept-Ranges” feature is defined in http 1.1 https://tools.ietf.org/html/rfc2616#section-14.5 And I know that the http stream seek feature is depend on The range requests. If we made http 1.0 requests by default, it may make some http servers that support range requests cannot seek the stream(like our case, you could use the following commands to test this: curl -I --http1.0 http://server/avstudy_resources/ogg/txh.opus curl -I --http1.1 http://server/avstudy_resources/ogg/txh.opus ). As http 1.1(even http2) is widely used nowadays, can you change this to http 1.1 instead? Or at least, provide a compile MACRO that give users an option to choose default http request version. Thanks. BR, Guoshun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20210217/10d9b9ee/attachment-0001.html>