W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > March 2019

Re: [dxwg] Inclusion of POST and PUT methods in content negotiation (#678)

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
Message-ID: <issue_comment.created-468716988-1551456537-sysbot+gh@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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 20 March 2019 21:59:26 UTC