Subject: #462, was: p5: editorial suggestions

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Jun 2013 17:35:07 +0200

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?

> * 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?

> 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?

> * 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.

> * 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"?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Jun 2013 08:58:23 -0700

>> * 3.1 "...and only if the result of their evaluation is leading toward a 200 (OK) response."  This is a bit informal...

"would result in"?

> 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.

> 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.

> But then it doesn't seem to say exactly the same thing.

Well, that's not good, is it?

>> * 4.3 last paragraph places a requirement on clients to "record" sets of ranges; how exactly do they meet this requirement? Terminology seems strange.

WFM.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Jun 2013 18:42:11 +0200

>>> * 3.1 "...and only if the result of their evaluation is leading toward a 200 (OK) response."  This is a bit informal...

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."

?

> Yes; I think just drop the "if the requested…" clause.

Yes (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>)

> Perhaps. Looking at this again, I'm less concerned than I was, but adding that text might be helpful.

Ok.

> 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.

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Jun 2013 09:52:12 -0700

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

> 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.

> It wouldn't be good, but it probably also wouldn't be something we can change right now.
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Jun 2013 20:39:27 +0200

On 2013-06-20 18:52, Mark Nottingham wrote:
> ...
> ...

OK; see <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2299>.

> ...

>> ...

I opened a separate ticket for tracking this one: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/489>.

Best regards, Julian