SIDN / ietf-epp-restful-transport

RESTful transport for EPP
Other
3 stars 4 forks source link

Content negotiation - synchronisation of content type #53

Open pawel-kow opened 6 months ago

pawel-kow commented 6 months ago

Why is this needed

The client MUST synchronize the value for the Content-Type and Accept headers, for example a client MUST NOT send an XML formatted request message to the server, while at the same time requesting a JSON formatted response message. The server MUST use the Content-Type HTTP header to indicate the media type used for the representation in the response message body. The server MUST return HTTP status code 406 (Not Acceptable) or 415 (Unsupported Media Type) when the client requests an unsupported media type.

Aren't the existing content negotiation methods in HTTP enough? In case of mixed support for request and response manifested by different Content-Type and Accept headers the server may decide based on it's own implementation if such request can be processed, or not and return 406 or 415 accordingly. More important would be to make a clear indication, that in case of 406 or 415 response the whole request needs to be rejected and MUST not be processed by the server.