HTTP allows for multiple representations of a resource. The Accept header allows the client to choose the representation of the resource.
GET /foo/bar HTTP/1.1
Accept: application/pdf
GET /foo/bar HTTP/1.1
Accept: text/html
GET /foo/bar HTTP/1.1
Accept: image/svg+xml
If the response is 200 OK, the entity is expected to be the resource as that content-type.
But in the spec (RFC 2616), there are a lot of references to entities that aren’t resources: 201 Created, 202 Accepted, 409 Conflict, 5xx, etc.
For example, for a 403 Forbidden response:
The server understood the request, but is refusing to fulfill it…If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity.
But what is the type of the entity? An HTML page? JSON?
As I read the standard, the Accept header applies only to the resource entity. It would be odd to generate a PDF of why the server was in error, just because the request was for an application/pdf.
There is a way to have multiple representations of resources. Is there a standard mechanism to have multiple representations of errors? (In my case, there are clients that either use primarily JSON, or primarily XML.)
I realize I can always make a X-Paul-Conflict-Accept and the X-Paul-Create-Accept and the X-Paul-Forbidden-Accept headers; I was curious if there was a usual way of handling this.
RFC2616 states: ” Any response containing an entity-body MAY be subject to negotiation, including error responses.” This means that it is acceptable to use the Accept header for this purpose, but that the server is not required to do so (it may choose to ignore the browser’s preferences for error messages).
Note that typically, a browser would not send a header that looks like your examples:the usual way of using the Accept header is to list all formats you are capable of understanding in order of preference, not just a single format. The application to error messages is more apparent in this case, as rather than requesting “application/pdf”, the browser would be more likely to request “application/pdf, txt/html, text/plain”, which the server is able to fulfill.