Specify PATCH

No description provided.

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?

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

@dmitrizagidulin

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

@dmitrizagidulin

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

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.

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.

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.

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?

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.

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.

Caught up on RFC5789, and I think LDP is awkward at that point. I think it makes zero sense to add Accept-Patch to OPTIONS *, but LDP doesn't qualify that case. The RFC makes the intention much clearer than LDP does:

The presence of a specific patch document format in this header indicates that that specific format is allowed on the resource identified by the Request-URI.

I think we need to tighten this up a bit, but also make clear that you don't need Accept-Patch on OPTIONS *.

@kjetilk

@kjetilk all of the section 4 sub-sections apply only to resource requests.

From the non-normative introduction, which is not normative but can help resolve ambiguities:

The following sections define the conformance rules for LDP servers when serving LDPRs. - ldp

More importantly, 4.2.7.1 explicitly refers only to ldp resources:

When a LDP server supports this method, this specification imposes the following new requirements for LDPRs. - ldp

Hmmm, right, that's a good point.

Wrote an overview of what we need to consider for SPARQL Update in #125 , and it got pretty lengthy.

Jotting this down for later:

One criteria to emphasise in the Solid spec is PATCH's atomicity requirement. It is sufficiently clear in RFC 5789:

The atomicity requirement holds for all directly affected files.

and what that entails. The Solid spec will have a global atomicity requirement ( #137 ) on creating nested containers when necessary and error if not possible. So, the requirements are well aligned.

Potential errors should be reported from general (can create nested containers?) to specific (can modify resource?)

I think that to advance this, we need to free ourselves from the requirements of SPARQL Update, as the number of issues to be settled there is pretty large, and it is best done in a panel.

So, nevermind my list above, what do we really need to agree on to find rough consensus on this one?

We agree on PATCH being required. It may require one or more specified ways to perform an update. If/when SPARQL Update and other approaches are cleared, the PATCH section can refer to them.

There are other relatively minor things that's in agreement eg. PATCH appears in Allow, Allow-Patch in some places (I think for the sake of uniformity, it should also be in OPTIONS * but this is not a show stopper for rough consensus right now), atomicity expectations, .. There are no particular restrictions on the kind of resources that would allow PATCH eg. containers and regular resources can be PATCH'd. It is only the formats that's of a concern that can be addressed.

Right, and since we have freed ourselves somewhat from the shacles of LDP since we had most of the discussion, I think we can go for something like

OPTIONS * MUST include Allow: PATCH, MAY include Accept-Patch with a list of media types.
HEAD, GET and OPTIONS on the resource itself, MUST include Allow: PATCH, and MUST include Accept-Patch with a list of media types.
As you say, any resource can be PATCHed, it is just whether there is a media type that determines it. 415 if it doesn't.

Then, we need to say something around atomicity.

Is that it? Can we move to rough consensus?

Navigation Menu

Repository navigation

Specify PATCH #85

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Specify PATCH #85

Description

Activity

dmitrizagidulin commented on Oct 5, 2019

kjetilk commented on Oct 7, 2019

kjetilk commented on Nov 15, 2019

csarven commented on Nov 15, 2019

kjetilk commented on Nov 15, 2019

csarven commented on Nov 15, 2019

kjetilk commented on Nov 15, 2019

csarven commented on Nov 17, 2019

kjetilk commented on Nov 18, 2019

csarven commented on Nov 18, 2019

kjetilk commented on Nov 18, 2019

kjetilk commented on Nov 19, 2019

19 remaining items

JordanShurmer commented on Nov 26, 2019

kjetilk commented on Nov 26, 2019

kjetilk commented on Nov 26, 2019

csarven commented on Jan 12, 2020

kjetilk commented on Jan 16, 2020

csarven commented on Jan 16, 2020

kjetilk commented on Jan 16, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions