Proposal: Accept-Put header for supported representations for PUT requests

[csarven]

The set of accepted representations of a resource can differ, independent of the HTTP request method when creating or updating resources.

As there is Accept-Patch and Accept-Post headers to set supported representations for PATCH and POST requests, the intention for the Accept-Put header is to advertise the supported representations for PUT requests.

The Accept-Put header was initially and casually mentioned in #195 (comment) and with some support in #195 (comment) .

[acoburn]

I am generally supportive of this proposal.

One thing to clarify would be how to represent both RDF formats and non-RDF formats. If a server supports arbitrary binary formats (e.g. LDP-NR), what would this header look like?

Would a header such as:
Accept-Put: text/turtle, application/ld+json

mean that image/jpeg is not acceptable? Does Accept-Put only refer to the supported RDF serializations? i.e. is the list meant to be exhaustive or is it just a hint to clients? Should a */* value be included to indicate arbitrary binary formats?

[csarven]

Ack #43 .

The proposed text in #201 is based off Accept-Patch and Accept-Post. As I read it, the absence of a mediatype in the Accept-Put value does not entail unacceptable. What's implied is equivalent to not using Accept-* ie. clients can make a request using any mediatype and server may accept as usual. That's not particularly useful to clients using Accept-* but at least the restriction is not there if unlisted.

A "smart" client can make some decisions based on other information in the spec. For instance, it is probably worthwhile for a client to not bother to check Accept-Put on a container URI to see if server allows image/jpeg. In theory it could, and in theory server might allow that mediatype but all unlikely for both. Just to push this line of thought a bit further: image/svg+xml may be supported on the container (probably because of RDFa support) - to have a graph(ic) of the container/index document.

In

Accept-Put: text/turtle, application/ld+json

clients could deduce that this is probably a resource that's best represented as a RDF graph, so image/jpeg is likely to be rejected if requested. Accept-Put is for any format, not only RDF serializations.

Servers can of course use wildcards and subtypes. And yes, */* would indicate that all formats are allowed. I don't think it needs to be called out but reasonable to have non-normative text as guideline.

---

I'm not sure why accept-params are left out in both Accept-Patch and Accept-Post. Wouldn't supporting the q parameter help reduce the ambiguity you are raising? I'd be for changing the current definition of Accept-Put (in PR) to allow the q parameter. So, remove:

minus the optional accept-params BNF production, since the latter does not apply to Accept-Put.

Any potential security concerns that escapes me?

[csarven]

Noting here that although #201 is now merged, I've followed up on the above with @acoburn to make sure that this issue is adequately addressed and no major oversights for the time being. I'm quoting Aaron from a conversation for the record in case it is helpful to future readers which resolves the q consideration from the above comment - the obvious that I've overlooked:

I'm not really sure why you would include the q param on the Accept-* methods. The use of q in Accept request headers gives the server an opportunity to rank preferences as expressed by a client. IOW, a client can say: "I'll accept any of these four serializations, in the following order of preference", For Accept-* response headers, why would the server be expressing a preference in the serialization? Content-negotiation should be client-driven. If a server supports three different mechanisms, why would one of those be better than another? My opinion would be: a server either supports something or it doesn't, it's up to a client to indicate preference. Therefore, I don't see why a server would indicate preferences with a q header.