Specify PATCH

[csarven]

[dmitrizagidulin]

Reminder to discuss: What to do about the MS-Author-Via: SPARQL header? (see PR nodeSolidServer/node-solid-server#1313 for example). (I bring it up here because it's PATCH-related.)
Does it need to be added to the spec? As a MUST or a MAY?

[kjetilk]

Just wondering if my "RDF Merge payload into document" might make be less problematic with PATCH... I just think it really needs to be a feature, the intuition for something like that to exist is very strong in me... :-)

[kjetilk]

Just wanting to post this somewhere as a note to self, since we need to specify this behaviour, which is mostly correct:

        # HTTP/1.1 415 Unsupported Media Type
        # Connection: close
        # Date: Fri, 15 Nov 2019 00:12:28 GMT
        # ETag: W/"2b-rKTuKHccg1SjlLhItRjeKZPSFY4"
        # Vary: Accept, Authorization, Origin
        # Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
        # Content-Length: 43
        # Content-Type: text/plain; charset=utf-8
        # Access-Control-Allow-Credentials: true
        # Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate, MS-Author-Via
        # Link: <alice_share_bob.txt.acl>; rel="acl", <alice_share_bob.txt.meta>; rel="describedBy", <http://www.w3.org/ns/ldp#Resource>; rel="type"
        # MS-Author-Via: SPARQL
        # Set-Cookie: connect.sid=[...] Path=/; Expires=Sat, 16 Nov 2019 00:12:28 GMT; HttpOnly; Secure
        # X-Powered-By: solid-server/5.2.1
        # 
        # Unsupported patch content type: text/plain
        # No expected headers set

[csarven]

@dmitrizagidulin IMO, we shouldn't bother to bring along a propriety header like MS-Author-Via. I don't quite see what it adds meanwhile Allow, Accept-*..

@kjetilk Anything in particular that's incorrect or inadequate? I'm assuming the key things in that example is the method and the content type.

[kjetilk]

@dmitrizagidulin IMO, we shouldn't bother to bring along a propriety header like MS-Author-Via. I don't quite see what it adds meanwhile Allow, Accept-*..

IIRC, @timbl was OK with MS-Author-Via, it is a de facto standard, and even though it hasn't (AFAIK) been through any open standardization process, there aren't any particular strings attached to it, so it can be used. The other headers don't point to SPARQL specifically.

@kjetilk Anything in particular that's incorrect or inadequate? I'm assuming the key things in that example is the method and the content type.

Basically, mainly that this is a LDP-NR, and it can't be edited with SPARQL, so it shouldn't be there in this case even if it is there for LDP-RS. Also, with ref to #118, the POST operation should possibly not be in the Allow header either.

But the observation that 415 should be used when you have no patch algo is a good one. Though for text/* it should be possible to use a diff -u patch, but AFAIK, there exists no authoratitive MIME type for that…

[csarven]

Isn't Allow: PATCH, Accept-Patch: application/sparql-update precise and sufficient?

Wouldn't updating text/* by any means simply left unspecified in the spec? I agree re 415.

[kjetilk]

Isn't Allow: PATCH, Accept-Patch: application/sparql-update precise and sufficient?

Actually... Yes! /me takes note to read RFC5789 in full... :-) Sorry.

Wouldn't updating text/* by any means simply left unspecified in the spec? I agree re 415.

Yes, it was the distinction between LDP-RS and LDP-NR that was the important part of my comment.

[csarven]

A bit more on the HTML and XML family: https://tools.ietf.org/html/rfc7351 and https://tools.ietf.org/html/rfc5261 is one way to have PATCH work for XML compatibles; XHTML and Polyglot markup. Unlikely to work well with HTML serialisations in general eg. those using optional tags. SVG and MathML should be fine. If a server supports XML Patch, application/xml-patch+xml will be listed in Accept-Patch.

Someone can correct me on this but AFAIK application/sparql-update is the only one we have implementation experience with, so that should probably be the only one appearing in the spec - with some requirement level.

I don't think the spec needs to bring any attention to LDP-NR or LDP-RS. Simply, if server allows certain methods cross content type for a resource, it can be known through Allow and Accept-*. That makes it possible for servers to advertise media types they support for PATCH - which is already an LDP requirement.

[kjetilk]

OK, so something around "If the server supports PATCH, it MUST advertize the media types it supports through the Accept-Patch header, and MUST respond with 415 if manipulation is attempted through other media types"? Or does this already follow from RFC5789?

[csarven]

If the server supports PATCH, it MUST advertize the media types it supports through the Accept-Patch header

Like I said, already in LDP: https://www.w3.org/TR/ldp/#ldpr-patch-acceptpatch

MUST respond with 415 if manipulation is attempted through other media types

I think that's just RFC 7231.

[kjetilk]

If the server supports PATCH, it MUST advertize the media types it supports through the Accept-Patch header

Like I said, already in LDP: https://www.w3.org/TR/ldp/#ldpr-patch-acceptpatch

Yeah, but... Perhaps I should defer commenting until I have caught up on RFC5789, but it seems terribly underspecified; It doesn't seem useful at all to know that a server supports a certain patch media type, for it to be useful, it needs to be known for each media type, or at the very least for each interaction model.