Ticket #285 (closed design: fixed)
Strength of requirements on Accept re: 406
|Reported by:||email@example.com||Owned by:||firstname.lastname@example.org|
|Component:||p3-payload||Severity:||Active WG Document|
The definition of the 406 status code allows servers to override the clients' preferences:
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the header fields of an incoming response to determine if it is acceptable.
However, this isn't really reflected in the Accept-* header requirements; e.g., for Accept:
If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (Not Acceptable) response.
The SHOULD here needs to either be contextualised (perhaps by pasting in a similar note), and/or relaxed to a MAY. Likewise for other Accept-* headers.
- Owner set to email@example.com
- Status changed from new to assigned
- Owner changed from firstname.lastname@example.org to email@example.com
- Status changed from assigned to new
- Milestone changed from unassigned to 16
- Status changed from new to closed
- Resolution set to incorporated
- Status changed from closed to reopened
- Resolution incorporated deleted