Re: #461, was: p4: editorial suggestions

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:

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

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