Re: Ranges

[Julian Reschke <[e-mail]>]

On 2013-06-27 04:53, Adrien W. de Croy wrote:
> Just been working on range support.  P5 is great improvement over 2616
> btw, answers a lot of questions.
> some nits and queries...
> 1. 3.1 Range:
> Para 4 (p7)
>
> A proxy MAY either discard a
>     Range header field that contains a range unit it does not understand
>     or pass it to the next inbound server when forwarding the request.
>
>
>
>
>
> What does "next inbound server" mean?  Range is a request header,
> therefore these should only be going in 1 direction, and that's from
> client to server.  I'd propose
> "A proxy MAY discard a Range header field that contains a range unit it
> does not understand".
> Para 5 (p7)
> "

Agreed.

> A server that supports range requests ought to ignore or reject a
>     Range header field that consists of more than two overlapping ranges"
>
> does "ought to" mean SHOULD?  How is the rejection envisaged, a 416?

It's definitively not a SHOULD. I think it could be a "MAY" or a "can".

And yes, 416 already mentions this case.

> 2. If-Range
> p5 (v22) doesn't specify what to do if there is an invalid date
> specified (e.g. not a well formed date / fails parsing).  I would
> propose this is a non-match and therefore range processing is
> suppressed.  Shouldn't there be some warning or something if Range
> processing is suppressed for various reasons?  e.g.:
> use of weak etag (prohibited)
> empty If-Range (ignore?)
> bad date
> TIA
> Cheers
>
> Adrien

We usually do not specify behavior for broken messages, unless it's 
needed for security reasons. Does this case qualify?

Best regards, Julian