Subject: Re: #461, was: p4: editorial suggestions

From: Julian Reschke <[email-masked]>
Date: Thu, 02 May 2013 09:05:15 +0200

On 2013-05-01 01:26, Mark Nottingham wrote:
>
> On 01/05/2013, at 12:46 AM, Ken Murchison <[email-masked]> wrote:
>
>> On Tue, 30 Apr 2013 15:07:49 +0200, Julian Reschke wrote:
>>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>
>>>> * 3.1 "...instead they MUST respond with the 412 (Precondition Failed) status code."  This is too strong; e.g., what if authentication is needed? Suggest an "unless..." clause allowing other error status codes.
>>
>> The first paragraph of Section 5 seems to address the case of 401 and any other errors:
>>
>> "For each conditional request, a server must evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would perform the action associated with the request method). Preconditions are ignored if the server determines that an error or redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the choice of conditional."
>>
>> The second sentence in Section 3 references Section 5 as far as when preconditions are applied.  This seems sufficient to me, but perhaps that is because I have read the document several times and know what it says in its entirety.
>
> Unfortunately, some (many) people will read the MUST and just stop.

Not convinced. We could move the text into each status code description, 
but I don't think it makes things much clearer.

> Also, everywhere else we suggest the most sensible status code to use in a situation, barring exceptions (which is essentially what we're doing here), it's SHOULD; the MUST here seems sorely out of place.

Why?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 May 2013 12:28:49 +1000

On 02/05/2013, at 5:05 PM, Julian Reschke <[email-masked]> wrote:

> Not convinced. We could move the text into each status code description, but I don't think it makes things much clearer.
> 

Here's a small sample of similar requirements in p2 (there are many, many more):

* When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code.

* When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.

* If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).

* 4.3.4 "If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) or 204 (No Content) response SHOULD be sent to indicate successful completion of the request."

What makes this one a MUST but the rest SHOULDs? Or are we just using these terms completely arbitrarily?

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 May 2013 08:30:03 +0200

> What makes this one a MUST but the rest SHOULDs? Or are we just using these terms completely arbitrarily?

a) For some of these, MUST may be better.

b) It always has been MUST, why change it?

And most importantly:

c) A conditional header field may be used to protect a potentially 
destructive request to change a resource that has been updated in 
between. Clients must be able to rely on that this protection works (and 
they do rely on it now), so it is a MUST fail. The also rely on a 
specific status code being returned in this case for diagnostics, so I 
believe it has to remain a "MUST fail" with this specific code.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 May 2013 16:34:12 +1000

> a) For some of these, MUST may be better.

I thought you were interested in keeping changes minimal... :)

> b) It always has been MUST, why change it?

Because strictly interpreted, it can result in leaking information about resources that require authentication (among other nonsensical conditions).

> And most importantly:
> 
> c) A conditional header field may be used to protect a potentially destructive request to change a resource that has been updated in between. Clients must be able to rely on that this protection works (and they do rely on it now), so it is a MUST fail. The also rely on a specific status code being returned in this case for diagnostics, so I believe it has to remain a "MUST fail" with this specific code.

Great; we can make it MUST NOT apply the method, as we do elsewhere in several places already, whilst making the status code to return a SHOULD.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 May 2013 09:18:24 +0200

> I thought you were interested in keeping changes minimal... :)

I'm mainly interested to finish HTTP/1.1. This implies that we should 
now concentrate on fixing things that are broken. This does not appear 
to be broken.

> Because strictly interpreted, it can result in leaking information about resources that require authentication (among other nonsensical conditions).

How so?

"For each conditional request, a server MUST evaluate the request 
preconditions after it has successfully performed its normal request 
checks (i.e., just before it would perform the action associated with 
the request method). Preconditions are ignored if the server determines 
that an error or redirect response applies before they are evaluated. 
Otherwise, the evaluation depends on both the method semantics and the 
choice of conditional."

> Great; we can make it MUST NOT apply the method, as we do elsewhere in several places already, whilst making the status code to return a SHOULD.

I still don't understand the benefit, but I *do* see drawbacks.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 May 2013 17:20:51 +1000

Reminder - this is an editorial issue, you're in the driver's seat. :)

Thanks for explaining your reasoning, that's very appreciated at this stage of the process.

Cheers,

On 06/05/2013, at 5:18 PM, Julian Reschke <[email-masked]> wrote:

> I'm mainly interested to finish HTTP/1.1. This implies that we should now concentrate on fixing things that are broken. This does not appear to be broken.
> 
> "For each conditional request, a server MUST evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would perform the action associated with the request method). Preconditions are ignored if the server determines that an error or redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the choice of conditional."
> 
>>> And most importantly:
>>>