Re: #462, was: p5: editorial suggestions

[Mark Nottingham <[e-mail]>]

On 20/06/2013, at 9:42 AM, Julian Reschke <[e-mail]> wrote:

> On 2013-06-20 17:58, Mark Nottingham wrote:
>> 
>> On 20/06/2013, at 8:35 AM, Julian Reschke <[e-mail]> wrote:
>> 
>>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>> 
>>>> * 2.1 "A byte range operation MAY specify..."   This is the only place "operation" is used in the document; it should either be defined, or replaced by another term.
>>> 
>>> Done in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2296>.
>>> 
>>>> * 3.1 "...and only if the result of their evaluation is leading toward a 200 (OK) response."  This is a bit informal...
>>> 
>>> Any suggestions?
>> 
>> "would result in"?
> 
> I wasn't sure whether the current text is supposed to leave some wiggle room, but maybe that's not needed.
> 
> So maybe change
> 
> "The Range header field is evaluated after evaluating the preconditions of [Part4] and only if the result of their evaluation is leading toward a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response."
> 
> to
> 
> "The Range header field is evaluated after evaluating the preconditions of [Part4] and only if the result in absence of the Range header field would be a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response."
> 
> ?

Think so.


> 
>>>> * 3.1 "If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response."
>>>> 
>>>> Yet 4.4 says: "because servers are free to ignore Range, many implementations will simply respond with 200 (OK) if the requested ranges
>>>> are invalid or not satisfiable."
>>> 
>>> Actually, they'd return 200 even *if* the range is both valid and satisfiable, right? Should we clarify that?
>> 
>> Yes; I think just drop the "if the requested…" clause.
> 
> Yes (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>)
> 
>>>> I think sometimes responding with 200 is the right thing to do here sometimes, and so we shouldn't put a requirement against it. We could either remove the SHOULD, or qualify it with something that allows the server to make a judgement call.
>>> 
>>> 4.4 mentions as a possible reason to prevent clients from resubmitting invalid requests; is this what we should mention here?
>> 
>> Perhaps. Looking at this again, I'm less concerned than I was, but adding that text might be helpful.
> 
> Ok.
> 
>>>> * 4.3 first paragraph re-defines what validator strength is; this should just be a reference to p4.
>>> 
>>> But then it doesn't seem to say exactly the same thing.
>> 
>> Well, that's not good, is it?
> 
> It wouldn't be good, but it probably also wouldn't be something we can change right now.
> 
>>>> * 4.3 last paragraph places a requirement on clients to "record" sets of ranges; how exactly do they meet this requirement? Terminology seems strange.
>>> 
>>> Maybe "process"?
>> 
>> 
>> WFM.
> 
> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>
> 
> Best regards, Julian
>