Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

un-:processable? request returns "Unprocessable entity." with "Content-Type: application/json;charset=UTF-8" #275

Open
ghost opened this issue Mar 28, 2017 · 1 comment
Labels

Comments

@ghost
Copy link

ghost commented Mar 28, 2017

The following should not happen:

# http get localhost:3000/api/v1/...
HTTP/1.1 422 Unprocessable Entity
Content-Length: 21
Content-Type: application/json;charset=UTF-8
Date: Tue, 28 Mar 2017 15:24:09 GMT
Server: Jetty(7.6.13.v20130916)
Vary: Accept

Unprocessable entity.

I assume it is caused by:

(lib/defresource ... []
  :available-media-types ["application/json"]
  ...)

IMO Liberator should decide: Either return a default text in the given Content-Type, or return nothing at all. What it does right now creates weird error messages, when my tests fail:

FAIL "GET /... - status" at (test_handler.clj:50)
    Expected: 200
      Actual: 422
Exception in thread "main" java.lang.Exception: JSON error (unexpected character): U, compiling:(.../test_handler.clj:46:1)
        at clojure.lang.Compiler.load(Compiler.java:7391)
        ...
@ordnungswidrig
Copy link
Member

Thanks for the report this is actually a bug that is related to #82. The problem is that the default response for 422 in liberator is a string "Unprocessable entity" but the error response makes use of the negotiated content type, application/json in this case. Liberator threats Strings as a literal response which leads to the observer behaviour.

A workaround is to implement :handle-unprocessable-entity and return a proper response according to the content type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant