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: Kam Hay Fung via GitHub <sysbot+gh@w3.org>
Date: Wed, 06 Mar 2019 01:46:00 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-469932643-1551836759-sysbot+gh@w3.org>
@larsgsvensson , `HEAD` header is intended to fetch a response from a server identical to a `GET` response except the body part. `Accept-*` headers will sound a bit odd in a `GET` response to a `GET` request which does not have a message body.
 
When your `HEAD` approach is applied to a RESTful service, the result will get interesting. Before a client creates resource 123 in the server, it can interrogate the server about the profile(s) it supports using `HEAD`:
 
```
HEAD /a/resources/123 HTTP/1.1
Accept: application/xml
```
 
Since resource 123 does not yet exist, the server might return a 404 response. In order to tell the client about its supported profile(s), the server also needs to return the `Accept-*` headers:
 
```
HTTP/1.1 404 NOT FOUND
Accept-Post: application/xml
Accept-Profile: urn:example:profile1
```
 
Alternatively, the server could just return the following even when the resource does not exist:

```
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Profile: urn:example:profile1
Accept-Post: application/xml
Accept-Profile: urn:example:profile1
```
 
Are both these options valid?
 
Nevertheless, once the client works out the profiles supported by a server, the rest of your example makes sense.

-- 
GitHub Notification of comment by kamhayfung
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/678#issuecomment-469932643 using your GitHub account
Received on Wednesday, 6 March 2019 01:46:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:45:08 UTC