Re: #461, was: p4: editorial suggestions

[Julian Reschke <[e-mail]>]

On 2013-05-06 08:34, Mark Nottingham wrote:
>
> On 06/05/2013, at 4:30 PM, Julian Reschke <[e-mail]> wrote:
>>
>> a) For some of these, MUST may be better.
>
> 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.

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

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

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

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

Best regards, Julian