-
Notifications
You must be signed in to change notification settings - Fork 409
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
EOF exceptions on empty responses w/ :as :clojure [1.1.0] #257
Comments
Hm. This code makes it look like it's doing the right thing:
Let me check to see exactly what's in my response that's causing this kind of problem. |
The issue is that even with an empty body, there's still an non-nil :body, a FilterStream. so the conversion code is called, even when the FilterStream is empty. At the very least, a quick check of the content-length header would be an improvement. After that it gets more complicated. If mark is supported, you can attempt to read a single byte, then reset. Ideally, lower layers of clj-http would ensure that :body was nil if the actual response is empty. |
Verified this occurs in 1.1.0. |
Yes, I think this is a byproduct of the switch from a String body to a stream, in the past it the body could be nil as you said, but now it is always a stream (even if an empty one). I will work on fixing this. |
Ok, thanks. I think I can do a workaround by defining a custom coerce-response-body method that eats the EOF exception. |
Currently commented out (since it fails)
For anyone who may come across this problem, the quick & dirty workaround below may save a few minutes: (ns my-ns
(:require [clj-http.client :as http]))
(defmethod http/coerce-response-body :clojure [req resp]
(if (> (Integer/parseInt (or (get-in resp [:headers "Content-Length"]) "0")) 0)
(http/coerce-clojure-body req resp)
(assoc resp :body nil))) It is specific to :clojure but should be pretty easy to adapt to any format. Not the best example of sound engineering practices but I expect it to work till the problem is fixed. |
I just encountered that issue too. For now, @bilus's workaround seems to be working (thanks). |
This commit checks if the body is empty during clojure coercion. If it's empty, the body is set to nil. Previously, the test assumed the body would return as an empty string but the expected behavior per the convo in the issue is that nil should be returned.
This commit checks if the body is empty during clojure coercion. If it's empty, the body is set to nil. Previously, the test assumed the body would return as an empty string but the expected behavior per the convo in the issue is that nil should be returned.
This commit checks if the body is empty during clojure coercion. If it's empty, the body is set to nil. Previously, the test assumed the body would return as an empty string but the expected behavior per the convo in the issue is that nil should be returned.
This commit checks if the body is empty during clojure coercion. If it's empty, the body is set to nil. Previously, the test assumed the body would return as an empty string but the expected behavior per the convo in the issue is that nil should be returned.
The same problem occurs if a server sends an empty body with "content-encoding: gzip". clj-http/src/clj_http/client.clj Line 311 in 3da50bf
|
When a request returns a response that is empty in addition to the "content-encoding: gzip" header, clj-http would try to decode the response, causing an EOFException. This resolves this by attempting to read a single byte, and returning an empty byte array if there is no body. This also fixes the case where the body was attempted to be coerced and failed due to the `EOFException` Resolves #257
I finally pushed a commit for this, thanks for your patience! |
I have hit an issue where, when I supply the :as :clojure option, clj-http will always attempt to parse the response, even when blank.
This is not ideal for me, and is generally problematic for any HTTP request that may return a body (to be parsed as JSON or EDN, etc.) or may respond with a status code and empty body.
This has only just come up because of ring-middleware-format:0.5.0, which now allows responses that are truly empty (in the past, a nil body would be converted to the string "nil" or "null").
Here's the exception I'm hitting:
My suggestion is that the :as functionality return nil when the body is empty.
I'm attempting a workaround where I do not use :as, but do supply a custom middleware to do the same thing ... with the "empty" check.
The text was updated successfully, but these errors were encountered: