Closed cap10morgan closed 11 years ago
This is strange, as the ring spec is quite clear about the fact that :content-type
is a standard top-level key. It works fine with Jetty and Tomcat here. In what context are you testing this? In the meantime, I've added a fallback check on the header string key here 878f3c5db336be828020be9aa6d6292224b387b7 which cannot hurt anyway.
You know, I can't remember the context in which we were running into this. I should have put that into the issue originally. Sounds like it'll be fixed now regardless. Thanks!
The make-type-request-pred function appears to be looking for a :content-type key in the top-level request map, but :content-type lives in the :headers map. This causes it to not properly decode JSON request bodies in our testing (and it starts working when we assoc {:content_type "application/json"} into the request map.