Re: Lack of server controlled property in PUT?

On Thu, Oct 9, 2014 at 8:45 AM, Yves Lafon <ylafon@w3.org> wrote:

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


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


Agree that PUT is not efficient for this case.  I'd suggest PATCH as well.

- Steve

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