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

json/decode is called twice with clj-http if api operation.response.content is "*/*" #189

Open
felixdo opened this issue Oct 4, 2023 · 2 comments

Comments

@felixdo
Copy link

felixdo commented Oct 4, 2023

Hi, thanks for this amazing tool. It's what I've been looking for a long time.

I'm consuming an api that has an operation with response.content set to "/", whereas it actually produces application/json.
I'm using clj-http, and for this case, martian uses its { :as :auto } option. The server responds with content-type: application/json, so clj/http auto-coerces the result into a map, whereas the martian coercion interceptor still expects a string, and then fails when it calls cheshire to decode. I wonder what the best way to mitigate this would be (apart from fixing the api spec).

@oliyh
Copy link
Owner

oliyh commented Oct 4, 2023

Hi, thanks for your kind words.

I would say that it could simply check if the body is a string, and just pass it straight through if not. This should be a simple change (in fact I thought it already did this). I'll try to do it soon, or else PRs always welcome.

Cheers

@felixdo
Copy link
Author

felixdo commented Oct 4, 2023

Yes that would work, but not sure if it's the best solution. Maybe its not needed if we get it right earlier.

As a workaround, I just remove :as :auto in another interceptor that I insert after interceptors/coerce-response.

Maybe one could allow a customizable auto-encoder (e.g. via a special key in the encoders map)
I'm also not sure if there's really a valid use case to ever pass :as :auto, I would maybe consider removing it.
Then also.. you dont want to break existing clients, so maybe customizable auto-encoder is the way to go.

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

No branches or pull requests

2 participants