- From: Lars G. Svensson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Mar 2019 16:08:58 +0000
- To: public-dxwg-wg@w3.org
@kamhayfung I'm not entirely sure that this write-up addresses your concern but this is how I think about this. From what I've understood there are two sides of this. 1. When a client pushes content to a resource on a server using PUT or POST there is no contract as to what the server will return. 2. The client does not know what profiles a server accepts for a given resource.lined out For 1., my view is that the profile(s) of the content a server returns from a request are the same ones as those listed in the `Content-Profile` header field(s) returned from a HEAD request. So if a client wants to know what profiles _any_ kind of representation returned from a resource (be the verb GET, POST, PUT or PATCH) it can issue a HEAD request and it will know. This is (IMHO) only relevant for successful request, i. e. those that return a 2xx status code, more specifically 200, 201, 202 or 203, since 204 and 205 do not have message bodies. For 2., my idea was that the server can issue an `Accept-Profile` header field to indicate which profiles it's willing to accept when a client issues a PUT, POST or PATCH request against a resource. In this respect it's similar to the [`Accept-Post` header field](https://www.w3.org/TR/ldp/#header-accept-post) and [`Accept-Patch`](https://tools.ietf.org/html/rfc5789#section-3.1) specifying which media types a given resource on a server is capable of processing. This header field can be returned in _all_ kinds of requests (HEAD, GET, PUT, etc.) for that resource. If that is **not** what you mean, you can stop reading here, else here is my proposed text (to be introduced _after_ the current example "Using a Link-header to point to a list of available profiles". ============= Begin text ================== If a server accepts a client to push content to a resource using HTTP PUT, POST or PATCH it can signal which content profiles it can handle by including an `Accept-Profile` header field in _every response_ to a request for that resource. The server can combine this with an `Accept-Post` [LDP] and/or `Accept-Patch` [RFC 5789] header field to signal which media types it's willing to accept. There can be cases in which a server only supports specific combinations of media types and profiles for the same resource (e. g. content in RDF media types such as `text/turle` or `application/rdf+xml` is available in the profiles `urn:example:profile1` and `urn:example:profile2` whereas content in `application/marc` and `application/marcxml+xml` is available in the profile `urn:example:profile3`). In this case the server SHOULD examine the `Accept`-header sent by the client in order to determine which is the media type preferred by the client and include the corresponding profile URI(s) in its `Accept-Profile` header. Example: \# Client asks server which profiles it accepts for a resource HEAD /a/resource HTTP/1.1 Accept: application/xml -------------- \# Server answers which media types and profiles it can accept HTTP/1.1 200 OK Content-Type: application/xml Accept-Post: application/xml Accept-Profile: urn:example:profile1 -------------- \# Client POSTs content POST /a/resource HTTP/1.1 Accept: application/xml Content-Type: application/xml;encoding=UTF-8 Content-Length: 1234 Content-Profile: urn:example:profile1 \<lorem>\<ipsum>dolor sit ... \</ipsum>\</lorem> ------------------- \# Server responds that the resource was created at /a/resource#comment-12345 HTTP/1.1 201 Created Location: /a/resource#comment-12345 Content-Type: application/xml;charset=UTF-8 Content-Profile: urn:example:1 \# and includes the acceptable media-types and profiles again Accept-Profile: urn:example:1 Accept-Post: application/xml;charset=UTF-8 ============= End text ================== Is this the right direction? @RubenVerborgh, do you have strong views on this? -- GitHub Notification of comment by larsgsvensson Please view or discuss this issue at https://github.com/w3c/dxwg/issues/678#issuecomment-468716988 using your GitHub account
Received on Friday, 1 March 2019 16:09:02 UTC