Re: Conditional delete in LDP

Hi,

On Wed, Jun 25, 2014 at 8:05 PM, John Arwe <johnarwe@us.ibm.com> wrote:
>
> > shouldn't we move the conditional request phrases from PUT to the
> general section and make it apply to all write requests (at least PUT and
> DELETE) ?
>
> Thus, it sounds like we know what to do about "generic write" requests ...
> most often you'll be wise to make them conditional.
>
> I'm not sure at this point if you've changed your mind about the Delete
> portion of your original proposal, if you're drifting in that direction via
> the discussion, or are standing behind your original.  Certainly one Could
> use conditional requests at any point; that's just a vacuous re-statement
> of HTTP, on its own.  I have yet to see any (>0) conditional delete
> requests in practice, despite their theoretical possibility, which makes me
> lean in the Delete case towards relying on readers' ability to recognize
> what's possible (even if not explicitly re-stated) based on the normative
> references.  ...at least in the normative spec.  I'm not sure if others'
> experiences are different, however, and that would be useful information if
> they do differ.
>
Yes, I understand that conditional deletes are rare and not used in
practice that much. So I am ok with leaving it for the user to decide based
on other RFCs. My concern was motivated by specs such as RFC7232 where all
the state changing operations are considered in the same level in the text.

[[Conditionals can also be applied to state-changing methods, such as PUT
and DELETE, to prevent the "lost update" problem: one client accidentally
overwriting the work of another client that has been acting in parallel]]
[[If-Match is most often used with state-changing methods (e.g., POST, PUT,
DELETE) to prevent ...]]

While we are on etags, it might be important to put a best practise on
using strong etags if the server plan to allow conditional requests with
If-Match. A server MUST use a strong comparison function to evaluate an
If-match condition and strong comparison only succeeds with strong etags.
Though these are well-defined in RFC7232, it might be useful to highlight
them in the LDP Best Practices and Guidelines as we encourage their use in
the LDP Spec. Something along the lines of

[[Use strong etags

The LDP specification enforces the use of entity tags (either weak or
strong ones) as response ETag header values, for responses that contain
resource representations or successful responses to HTTP HEAD requests.
 Further, LDP encourages the use of conditional requests with If-Match
header in PUT (or state changing?) operations to prevent the lost update
problem.

If-Match condition validation requires the use of strong etags, thus the
servers that plan to use conditional requests with If-Match header must use
strong etags [RFC7232] ]]

Best Regards,
Nandana