We have one remaining time bomb at the moment. The comment in the code says:
If the accept header is set to a media type that the rate limiting filter cannot handle, the rate limiting filter should return a 406, or a body with some default media type (ignoring the accept header). This test assumes that the latter approach was taken, and that limits are retrieved from the origin service as xml, combined, and returned to the requestor. HTTP/1.0 spec dicatates that the former approach be taken, while HTTP/1.1 leaves it as an implementation decision.
Assuming we're only going to support HTTP/1.1, we should update the Rate Limiting filter to respond as if the client asked for XML. Alternatively, also support responding with a 406 if we detect the client is using HTTP/1.0.
- When running in Valve mode in Repose 8, Jetty rejects requests that are missing the Host header. This means we don't fully support HTTP/1.0 already.
- We should also consider the scenario where the client asks for a media type the filter cannot handle and specifically says that XML is not acceptable (i.e. Accept: application/xml;q=0.0).
During story grooming, we decided we're going to respond with a 406 in these situations.
We may want to add the Accept-Ranges header with the formats that we do support if that's what we think it is.
- The Rate Limiting filter returns a 406 when the Accept header indicates the client doesn't support any formats we support (XML and JSON).
- This includes the client saying it Accepts an unsupported format (e.g. "YAML") and saying it does not Accept XML.
- Be sure to consider the header quality (which means you'll have to grab all of the headers from the wrapper).
- The Rate Limiting filter continues to return JSON when there is no Accept header.
- The time bomb test is updated with the correct expectation.