httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Regression with range fix
Date Wed, 31 Aug 2011 21:00:23 GMT
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.

Mime
View raw message