httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <is...@jellybaby.net>
Subject Re: Fixing Ranges
Date Thu, 25 Aug 2011 19:11:51 GMT
On 25 Aug 2011, at 15:48, Plüm, Rüdiger, VF-Group wrote:

> For 2.3 the last one could be 3 state:
> 
> off - Don't do anything about that
> on - reply with 200 if misuse is detected.
> optimize - Do sorts and merges and fill too small chunks between the ranges.
> 
> Default for 2.3 would be optimize.

I don't know exactly how the PDF plugins work, but we might expect requests like:

HEAD /foo HTTP/1.1
Host: xxx.example

to learn the content length, followed by:

GET /foo HTTP/1.1
Host: xxx.example
If-Range: "bar"
Range: bytes=0-4095,8384511-8388607,4096-8384510,8384512-

(hoping to read the indexes at the start and end of the document first, then fill in the rest).


A default that forces the clients back to seeing only the whole entity seems too strong, especially
if httpd will now have better code to handle this case. Detecting misuse and handling that
with a 200 still fine though.

I expect that clients exist which would get confused at having small chunks filled in.
For example, a client that expects either a multipart/byte-ranges response or a whole-entity
200 (because the server doesn't accept ranges). With the above “optimize”, the client
instead gets a sorted and merged single-range response. Naive coding could have the client
believe that it is seeing the whole entity rather than just a range.

…yes, such a client is badly written but badly written clients can and do exist. If httpd
punishes their users unduly, httpd itself may attract some blame.

-- 
Tim Bannister – isoma@jellybaby.net


Mime
View raw message