Fork me on GitHub

about http-kit client, how does one generally deal with errors? clj-http has :throw-exceptions true/false. with http-kit, should one check for :errors after deref and then throw yourself?


yes basically. iirc httpkit catches all internal exceptions and propagates them as :error


do you know if it generates an error on certain status codes, like 400?


i believe not. i think :error is only exceptions like SSL/Timeouts/etc... but i will double check

ep11:09:16 shows that :error should be a throwable. see its also see the docstring:

"Issues an async HTTP request and returns a promise object to which the value
  of `(callback {:opts _ :status _ :headers _ :body _})` or
     `(callback {:opts _ :error _})` will be delivered.
  The latter will be delivered on client errors only, not on http errors which will be
  contained in the :status of the first.


Right, so:

user=> (type @(c/get ""))
Doesn't this mean every user of httpkit is going to write their own synchronous clj-http-ish wrapper?


wdym? like to do de-structuring/error-handling?


yeah, i suppose there is some forced boiler-plate there


maybe babashka could use a babashka.http-client namespace which removes this boilerplate, making it look like babashka.curl, but based on http-kit instead. while also adding http kit itself for async use.


then it could also become a drop-in replacement for babashka.curl


because you want non-2xx or 3xx to be treated as an error? i guess to be consistent you would want the same semantics for the async callback right?


babashka.http-client would only imitate clj-http with the synchronous interface


if you want async, you can use http-kit directly, but you would have to deal with more boilerplate yourself, which is a reasonably trade-off imo


ah, so they would be different namespaces in other words. you'd just be using http-kit for everything under the hood to reduce implementation complexity


(require '[babashka.http-client]) ;; implemented using httpkit, looks like clj-http sync, throws on a selection of status codes
(require '[org.httpkit.client]) ;; same as httpkit, SNI client already enabled by default


i personally dont mind the httpkit semantics. maybe because i got used to it, but it doesnt seem right to treat errors that happen on the level of SSL or TCP the same as HTTP errors. but for the compatibility reason with the current behavior it makes sense what you propose


Do you have a lot of :error checks in your httpkit code?


we can distinguish errors of status and errors on ssl level using an ex-info


or just re-throw the java exception and use an ex-info for status codes


I usually just want my script to exit with an error in case of a faulty request


i guess if its in the context of a script its one thing, but in the context of a long-running service at the company i work, we want to collect metrics for different response types, including per status code, but also for things like timeout/ssl errors. these can be important for back-pressure/circuit-breaking/retry considerations. but there are very different implications for 4xx vs 5xx vs timeouts vs sslerror which might be dynamic depending on the endpoint you're speaking with. also some apis will return success codes, but then return error messages/internal codes in the response body which must be parsed and considered. might point is in any case, eventually you start getting down into the granularity of status codes and exception/error types anyhow, so the boilerplate becomes unavoidable. but again, probably these considerations are not relevant in the majority of scripting cases and a binary success/error is enough


(require '[babashka.http-client]) ;; implemented using httpkit, looks like clj-http sync, throws on a selection of status codes
(require '[org.httpkit.client]) ;; same as httpkit, SNI client already enabled by default


Any possibility of adding,DigestInputStream to allow computation of hashes from input streams?