- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Thu, 9 Oct 2014 08:33:47 -0700
- To: Steve Speicher <sspeiche@gmail.com>
- Cc: Yves Lafon <ylafon@w3.org>, "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
- Message-ID: <CABevsUFHZoaoKhmuUe_bYYZc5mf0Oyefuo2BjvMCqCGqYPTB5Q@mail.gmail.com>
On Thu, Oct 9, 2014 at 5:58 AM, Steve Speicher <sspeiche@gmail.com> wrote: > On Thu, Oct 9, 2014 at 8:45 AM, Yves Lafon <ylafon@w3.org> wrote: > >> On Wed, 8 Oct 2014, Robert Sanderson wrote: >> >>> 1. 4.2.4.1 says: "LDP servers may ignore server-managed properties ... >>> if >>> they are not under client control." >>> 2. 4.2.4.3 says: "If an otherwise valid HTTP PUT request is received >>> that >>> attempts to change properties the server does not allow clients to >>> modify, >>> LDP servers must fail the request by responding with a 4xx range status >>> code (typically 409 Conflict)." >>> >>> To rephrase 1: LDP servers MAY ignore changes to server-managed >>> properties >>> that are not under client control. >>> To rephrase 2: LDP servers MUST error on changes to properties that are >>> not under client control. >>> >>> Assuming that "server-managed properties" are "properties", there is a >>> logical inconsistency, as far as we can tell. We think that this must be >>> addressed in the specification. (Sorry!) >>> >> >> I don't see the inconsistency here, one means mostly "client can try to >> modify it" even the change will not take place (like dcterms:modified that >> might be computed automatically), the second means "client is not allowed >> to try to change it", and 403 should be a better signal than 409 here. >> >> I don't see the inconsistency either, agreeing with Yves. We had a > fairly long discussion on suggested status codes, resulting in the language > of "typically 409", of course other may be valid for other cases. > When a client tries to change a server-managed property that is not under client control, does the server ignore the property and accept the rest of the request (under 4.2.4.1) or return an error for the entire request (under 4.2.4.3)? It clearly cannot do both. Or can it do either, at its discretion ... making 4.2.4.1 useless in practice as clients would have to allow for the situation when the server errors, and thus should always send the current value for the property. Thanks! Rob -- Rob Sanderson Technology Collaboration Facilitator Digital Library Systems and Services Stanford, CA 94305
Received on Thursday, 9 October 2014 15:34:15 UTC