Handle malformed Accept-Language Accept-Charset & Accept-Encoding

[lverns]

Fixes #199

Bad qvals (either out of range, not parsable to a float) in these headers will now cause a 400 status code to be returned.

I'm not overly happy with this because we are sending a 400 status code, but not passing through handle-malformed which means users of this library can't change the rendering by overriding handle-malformed.

The best they can do is check for the :liberator.core/throwable key on the response and add custom handling in middleware (e.g. ring), which may be good enough.

[ordnungswidrig]

Thanks for the patch, I will look into it soon. I wonder if 400 is the correct response for a malformed q-value. I think the http RFC suggests invalid values to be ignored, but I cannot think of a sensible default for an unparseable q-value: 0, 1, 0.5? In general I guess it's better to respond with some representation than returning an error. The client must verify that the response is in an expected format in any case.

[cch1]

Any update on when this might be merged?

[cch1]

ping!

[ordnungswidrig]

Hey @cch1, sorry for the delay.

In RFC7231 we can read for the Accept header:

If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.

We should prefer giving a valid response for an invalid Accept q value or returning an error. What about defaulting q in case of error with 0.01 so it will be elegible but not prefered?

[ordnungswidrig]

try-catch-default to 0.01 here.

[cch1]

That sounds like a good, pragmatic solution.

[lverns]

@ordnungswidrig Why 0.01? Is the idea to select a default value that is towards the bottom of the acceptable range for quality values, but leaves the actual minimum value (0.001) free in case the client correctly attaches it to some other entry?

[ordnungswidrig]

Hmmm, I'm not sure what the best would be in this case. The HTTP RFC suggest only to use three decimal places, so 0.001 is the smallest valid value. In the end this is just to make the server react as resilient as possible. If the client sends image/png;q=0.A;image/jpeg;q=0.1 then what would be a good response? We don't know of the client wanted to accept 0.1 for PNG or 0.9. But rather than sending no response I'd take the invalid one as the least acceptable for now.

[ordnungswidrig]

@lverns looks good! Can you add an entry to CHANGES.markdown, please? I will merge right away :-)

[ordnungswidrig]

Thanks for the patch!