Re: Lack of server controlled property in PUT?

On Wed, 8 Oct 2014, Robert Sanderson wrote:

> Dear all,
>
> To be more specific, in an attempt to get a response, we believe that there
> is an issue that needs to be addressed:
>
> 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.

>
> Further:
>
> 3.  We assert: Given that PUT (from 4.2.4.1) replaces the entire resource,
> the lack of presence of a property is an instruction to delete it.
> 4.  5.2.4.1 says:   "LDP servers should not allow HTTP PUT to update a
> LDPC?s containment triples; if the server receives such a request, it
> should respond with a 409 (Conflict) status code."
>
> Note: 5.2.4.1 follows from 4.2.4.3, and just reinforces that clients cannot
> directly modify the (server managed) containment property.
>
> Given 3. and 4. the implication is that clients MUST send exactly the same
> containment triples as the current state of the resource.
>
> We do not think this is a reasonable requirement for large containers (or
> in fact /any/ container) and makes PUT unimplementable in any practical
> sense.

That's why PATCH is a much more preferable solution in most cases.

>
> Further again:
>
> Given the scoping of 1. and 2. if there are properties that are added by
> the server, but are able to be modified by the client, they MUST always be
> included in the representation for PUT.  For example, every update to a
> container MUST include ldp:hasMemberRelation if that is able to be
> specified by the client.  The non-normative note under 4.2.4.3 clarifies
> that write-once properties (as hasMemberRelation might be) are NOT
> considered server-managed properties, and regardless of the inconsistency
> would thus not fall under the 4.2.4.1 clause.
>
> For systems with many server-managed properties (for example, we make ALL
> resources into BasicContainers) this makes for a large implementation
> cost.  We can eat that cost, but we would like to discuss if it's really
> necessary.
>
>
> Our proposal is to clarify that *omitting* any property that is managed by
> the server is acceptable, however including it with a value that is not the
> same as the current state would trigger the error condition as per 4.2.4.3
> / 5.2.4.1
>
>
> I would be happy to discuss on Columbus day call, and can un-regret myself
> for that purpose :)
>
> Rob
>
>
> On Fri, Oct 3, 2014 at 11:39 AM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> Hi all,
>>
>> A quick question that we're a little puzzled over and would appreciate
>> some confirmation on...
>>
>> In 4.2.4.1 (copied below for reference), servers must replace the entire
>> state of a resource, but they may ignore server-managed properties not
>> under client control, and anything more sophisticated is PATCH rather than
>> PUT.
>>
>> Does the clause about ignoring server-managed properties include both
>> presence and lack of presence?  For example, if I PUT a new set of
>> predicates about a Collection, and don't include the membership properties
>> in the representation, is it permissible for the server to ignore the *lack
>> of* those triples?
>>
>> Otherwise, it seems that you would need to submit the complete
>> representation with all, say, 100,000 membership triples, just to change a
>> label for the collection.  That would normally be PATCH, I know, but is
>> this a known special case or an unintended loophole?
>>
>> And, to be sure, this would ONLY apply for server managed properties, not
>> for other properties where the lack of the property would mean to delete
>> any existing triple, and to do otherwise would require PATCH.
>>
>> Thanks!
>>
>> Rob
>>
>> ----
>> 4.2.4.1 If a HTTP PUT is accepted on an existing resource, LDP servers
>> must replace the entire persistent state of the identified resource with
>> the entity representation in the body of the request. LDP servers may
>> ignore server-managed properties such as dcterms:modified and
>> dcterms:creator if they are not under client control. Any LDP servers that
>> wish to support a more sophisticated merge of data provided by the client
>> with existing state stored on the server for a resource must use HTTP
>> PATCH, not HTTP PUT.
>>
>>
>> --
>> Rob Sanderson
>> Technology Collaboration Facilitator
>> Digital Library Systems and Services
>> Stanford, CA 94305
>>
>
>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 9 October 2014 12:45:01 UTC