Open YoucTagh opened 1 year ago
That would be a different way of advertising then, which the Link
headers already do?
Quoting from the current draft:
The "Link" header indicates the profile of the returned representation but also points at two alternative representations, each of which conforms to another profile.
As I understand it, it does not have the semantics to convey a preference from a server to a client. On the other hand, the Accept-Profile
, when sent in a response, indicates the server's preferred profiles in the subsequent requests.
As I understand it, it does not have the semantics to convey a preference from a server to a client. On the other hand, the Accept-Profile, when sent in a response, indicates the server's preferred profiles in the subsequent requests.
Would that preference be to indicate "these are the only profiles that work for this resource"? If not, why would a server want to indicate which profiles a client should ask for?
That is my interpretation. Seems more realistic to me that a server lets a client know what it supports than a client asking a server for whichever profile. I wonder what the interpretation of @YoucTagh is.
This is also my interpretation. I can add that if the server uses the same accept profile
syntax, q-values could be used to indicate a preference for some profiles over others, a use case being that checking the conformance of a profile requires less computational power for the server.
What do you think of the idea to add a new subsection reflecting the new CN style Request Content Negotiation introduced in RFC 9110? This is similar to HTTP Client hints and
Vary/Allow
used in the document.Description of the CN style:
By sending an
accept-profile
header in a response, the server can influence the selection of an appropriate content for subsequent requests for a resource (i.e., to indicate a preferred profile for subsequent requests for that resource). An example of client/server interaction:Client request example:
Server response example: