On Wednesday 31 August 2011, Joe Orton wrote: > On Tue, Aug 30, 2011 at 08:51:55PM +0200, Stefan Fritsch wrote: > > The first regression report, though slightly too late for the > > vote: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639825 > > > > The byterange_filter.c in the Debian update is exactly the one > > from 2.2.20. I will keep you updated. > > Hi; I'm just back from holiday and catching up. > > The behaviour changes in the patch which could feasibly break > non-compliant clients are: > > a) using 200 in some cases where a 206 response would end up being > larger
For the first user who complained, I think this is the problem. His client does a "Range: bytes=0-" request. I suspect the 200 (instead of 206) response to this request lets the client assume that the server does not support ranges at all. I will try to get this verified. > > b) using a chunked response where previously C-L was always used, > in cases where >=32 ranges are being returned > > Anything else to watch out for? c) a request with a byterange beyond the end of the file used to return 416 but now returns 200. This is a violation of a RFC2616 SHOULD. We didn't catch this when testing. This is how mplayer seems to determine that it has reached the end of file. This seems a rather stupid thing to do unless mplayer assumes that the file may grow. But as it's a SHOULD, we should fix it.
