You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I described my issue on Stack Overflow over here, and the more I think about it, the more it seems like a bug.
I don't know if it's okay to just link it so here's a quick brief of the issue.
Providing a :handle-not-found is ignored as well, checked for regression on versions 0.15.2, 0.15.1, 0.15.0 but same results, and it only happens with the "application/json" media type. E.g. "application/edn" works perfectly. No Ring middleware is used (not even site/api defaults).
And as I wrote over there, I'm not sure if I just misused the library but it does seem like a bug or at least something to enhance. Still, if that's the case I would really appreciate some help!
The text was updated successfully, but these errors were encountered:
This doesn't trigger the error you describe. But you're correct in that the above is not a proper HTTP response: the content type is declared JSON but the actual content is liberator's default response, as string "Resource not found". This will most likely trigger an error on the client side, and maybe that's what you're observing.
In liberator, whenever a handler returns a String then this is returned as a "literal" response body, as it's the case when a handler returns a File, ByteArray or InputStream. Unfortunately this kind of conflicts with what the handlers return by default.
I suggest you add your own declaration of for :handle-not-found. When you only ever return JSON it's as simple as :handle-not-found {:msg "Resource not found"}.
Why does liberator return Strings "literally" you may ask? This is a conveinience so you can return a properly formatted response from a handler without worrying about how :as-response coerces it to a represention depending on the negotiated media type.
Need to look how to prove better handler defaults which work with non plaintext media types.
ordnungswidrig
changed the title
JSON representation issue when resource does not exist
Default handler responses returned are invalid JSON [Was: JSON representation issue when resource does not exist]
Sep 17, 2018
Wow, it really was the client (Chrome's ARC). Thank you so much for your help!
I'm not familiar with the codebase so this might be too naive of me but wouldn't it be possible to just get the default handlers' values through as-response? I imagine that would be the clean way to do it (if context is there at that point).
I described my issue on Stack Overflow over here, and the more I think about it, the more it seems like a bug.
I don't know if it's okay to just link it so here's a quick brief of the issue.
The following resource:
Yields a 404 response with the following text:
Providing a
:handle-not-found
is ignored as well, checked for regression on versions0.15.2
,0.15.1
,0.15.0
but same results, and it only happens with the "application/json" media type. E.g. "application/edn" works perfectly. No Ring middleware is used (not even site/api defaults).And as I wrote over there, I'm not sure if I just misused the library but it does seem like a bug or at least something to enhance. Still, if that's the case I would really appreciate some help!
The text was updated successfully, but these errors were encountered: