Giter Club home page Giter Club logo

clj-http's Introduction

clj-http documentation

https://img.shields.io/clojars/v/clj-http.svg https://github.com/dakrone/clj-http/workflows/Clojure%20CI/badge.svg https://badges.gitter.im/clj-http/Lobby.svg

Table of Contents

Branches

There are branches for the major version numbers:

  • 2.x (no longer maintained except for security issues)
  • 3.x (current stable releases and the main Github branch)
  • master (which is 4.x, unreleased, based on version 5 of the Apache HTTP Client)

Introduction

Overview

clj-http is an HTTP library wrapping the Apache HttpComponents client. This library has taken over from mmcgrana’s clj-http.

Philosophy

The design of clj-http is inspired by the Ring protocol for Clojure HTTP server applications.

The client in clj-http.core makes HTTP requests according to a given Ring request map and returns Ring response maps corresponding to the resulting HTTP response. The function clj-http.client/request uses Ring-style middleware to layer functionality over the core HTTP request/response implementation. Methods like clj-http.client/get are sugar over this clj-http.client/request function.

Installation

clj-http is available as a Maven artifact from Clojars.

With Leiningen/Boot:

[clj-http "3.13.0"]

If you need an older version, a 2.x release is also available.

[clj-http "2.3.0"]

clj-http 3.12.x supports clojure 1.6.0 and higher. clj-http 3.13.x supports clojure 1.8.0 and higher. clj-http 4.x will support clojure 1.7.0 and higher.

Quickstart

The main HTTP client functionality is provided by the clj-http.client namespace.

First, require it in the REPL:

(require '[clj-http.client :as client])

Or in your application:

(ns my-app.core
  (:require [clj-http.client :as client]))

The client supports simple get, head, put, post, delete, copy, move, patch, and options requests. Response are returned as Ring-style response maps:

HEAD

(client/head "http://example.com/resource")

(client/head "http://example.com/resource" {:accept :json})

GET

Example requests:

(client/get "http://example.com/resources/id")

;; Setting options
(client/get "http://example.com/resources/3" {:accept :json})
(client/get "http://example.com/resources/3" {:accept :json :query-params {"q" "foo, bar"}})

;; Specifying headers as either a string or collection:
(client/get "http://example.com"
            {:headers {"foo" ["bar" "baz"], "eggplant" "quux"}})

;; Using either string or keyword header names:
(client/get "http://example.com"
            {:headers {:foo ["bar" "baz"], :eggplant "quux"}})

;; Completely ignore cookies:
(client/post "http://example.com" {:cookie-policy :none})
;; There are also multiple ways to handle cookies
(client/post "http://example.com" {:cookie-policy :default})
(client/post "http://example.com" {:cookie-policy :netscape})
(client/post "http://example.com" {:cookie-policy :standard})
(client/post "http://example.com" {:cookie-policy :standard-strict})

;; Cookies can be completely configurable with a custom spec by adding a
;; function to return a cookie spec for parsing the cookie. For example, if you
;; wanted to configure a spec provider to have a certain compatibility level:
(client/post "http://example.com"
             {:cookie-spec
              (fn [http-context]
                (println "generating a new cookie spec")
                (.create
                 (org.apache.http.impl.cookie.RFC6265CookieSpecProvider.
                  org.apache.http.impl.cookie.RFC6265CookieSpecProvider$CompatibilityLevel/IE_MEDIUM_SECURITY
                  (PublicSuffixMatcherLoader/getDefault))
                 http-context))})
;; Or a version with relaxed compatibility
(client/post "http://example.com"
             {:cookie-spec
              (fn [http-context]
                (println "generating a new cookie spec")
                (.create
                 (org.apache.http.impl.cookie.RFC6265CookieSpecProvider.
                  org.apache.http.impl.cookie.RFC6265CookieSpecProvider$CompatibilityLevel/RELAXED
                  (PublicSuffixMatcherLoader/getDefault))
                 http-context))})

;; Sometimes you want to do your own validation or something, which you can do
;; by proxying the CookieSpecBase. Note that this doesn't actually return the
;; cookies, because clj-http does its own cookie parsing. If you want to store
;; the cookies from these methods you'll need to use a cookie store or put it in
;; some datastructure yourself.
(client/post "http://example.com"
             {:cookie-spec
              (fn [http-context]
                (proxy [org.apache.http.impl.cookie.CookieSpecBase] []
                  ;; Version and version header
                  (getVersion [] 0)
                  (getVersionHeader [] nil)
                  ;; parse headers into cookie objects
                  (parse [header cookie-origin] (java.util.ArrayList.))
                  ;; Validate a cookie, throwing MalformedCookieException if the
                  ;; cookies isn't valid
                  (validate [cookie cookie-origin]
                    (println "validating:" cookie))
                  ;; Determine if a cookie matches the target location
                  (match [cookie cookie-origin] true)
                  ;; Format a list of cookies into a list of headers
                  (formatCookies [cookies] (java.util.ArrayList.))))})

;; If you have created your own registry for cookie policies, you can provide
;; :cookie-policy-registry to use it. See
;; clj-http.core/create-custom-cookie-policy-registry for an example of a custom
;; registry
(client/post "http://example.com"
             {:cookie-policy-registry my-custom-policy-registry
              :cookie-policy "my-policy"})

;; Need to contact a server with an untrusted SSL cert?
(client/get "https://alioth.debian.org" {:insecure? true})

;; If you don't want to follow-redirects automatically:
(client/get "http://example.com/redirects-somewhere" {:redirect-strategy :none})

;; Only follow a certain number of redirects:
(client/get "http://example.com/redirects-somewhere" {:max-redirects 5})

;; Avoid throwing exceptions if redirected too many times:
(client/get "http://example.com/redirects-somewhere" {:max-redirects 5 :redirect-strategy :graceful})

;; Throw an exception if the get takes too long. Timeouts in milliseconds.
(client/get "http://example.com/redirects-somewhere" {:socket-timeout 1000 :connection-timeout 1000})

;; Query parameters
(client/get "http://example.com/search" {:query-params {"q" "foo, bar"}})

;; "Nested" query parameters
;; (this yields a query string of `a[e][f]=6&a[b][c]=5`)
(client/get "http://example.com/search" {:query-params {:a {:b {:c 5} :e {:f 6}}}})

;; Provide cookies — uses same schema as :cookies returned in responses
;; (see the cookie store option for easy cross-request maintenance of cookies)
(client/get "http://example.com"
            {:cookies {"ring-session" {:discard true, :path "/", :value "", :version 0}}})

;; Tell clj-http not to decode cookies from the response header
(client/get "http://example.com" {:decode-cookies false})

;; Support for IPv6!
(client/get "http://[2001:62f5:9006:e472:cabd:c8ff:fee3:8ddf]")

;; Super advanced, your own http-client-context and request-config
(client/get "http://example.com/get"
            {:http-client-context my-http-client-context
             :http-request-config my-request-config})

The client will also follow redirects on the appropriate 30* status codes.

The client transparently accepts and decompresses the gzip and deflate content encodings.

:trace-redirects will contain the chain of the redirections followed.

PUT

(client/put "http://example.com/api" {:body "my PUT body"})

POST

;; Various options:
(client/post "http://example.com/api"
             {:basic-auth ["user" "pass"]
              :body "{\"json\": \"input\"}"
              :headers {"X-Api-Version" "2"}
              :content-type :json
              :socket-timeout 1000      ;; in milliseconds
              :connection-timeout 1000  ;; in milliseconds
              :accept :json})

;; Send form params as a urlencoded body (POST or PUT)
(client/post "http://example.com" {:form-params {:foo "bar"}})

;; Send form params as a json encoded body (POST or PUT)
(client/post "http://example.com" {:form-params {:foo "bar"} :content-type :json})

;; Send form params as a json encoded body (POST or PUT) with options
(client/post "http://example.com" {:form-params {:foo "bar"}
                                   :content-type :json
                                   :json-opts {:date-format "yyyy-MM-dd"}})

;; You can also specify the encoding of form parameters
(client/post "http://example.com" {:form-params {:foo "bar"}
                                   :form-param-encoding "ISO-8859-1"})

;; Send form params as a Transit encoded JSON body (POST or PUT) with options
(client/post "http://example.com" {:form-params {:foo "bar"}
                                   :content-type :transit+json
                                   :transit-opts
                                   {:encode {:handlers {}}
                                    :decode {:handlers {}}}})

;; Send form params as a Transit encoded MessagePack body (POST or PUT) with options
(client/post "http://example.com" {:form-params {:foo "bar"}
                                   :content-type :transit+msgpack
                                   :transit-opts
                                   {:encode {:handlers {}}
                                    :decode {:handlers {}}}})

;; Multipart form uploads/posts
;; takes a vector of maps, to preserve the order of entities, :name
;; will be used as the part name unless :part-name is specified
(client/post "http://example.org" {:multipart [{:name "title" :content "My Awesome Picture"}
                                               {:name "Content/type" :content "image/jpeg"}
                                               {:name "foo.txt" :part-name "eggplant" :content "Eggplants"}
                                               {:name "file" :content (clojure.java.io/file "pic.jpg")}]
                                   ;; You can also optionally pass a :mime-subtype
                                   :mime-subtype "foo"})

;; Multipart :content values can be one of the following:
;; String, InputStream, File, a byte-array, or an instance of org.apache.http.entity.mime.content.ContentBody
;; Some Multipart bodies can also support more keys (like :encoding
;; and :mime-type), check src/clj-http/multipart.clj to see all flags

;; Apache's http client automatically retries on IOExceptions, if you
;; would like to handle these retries yourself, you can specify a
;; :retry-handler. Return true to retry, false to stop trying:
(client/post "http://example.org" {:multipart [["title" "Foo"]
                                               ["Content/type" "text/plain"]
                                               ["file" (clojure.java.io/file "/tmp/missing-file")]]
                                   :retry-handler (fn [ex try-count http-context]
                                                    (println "Got:" ex)
                                                    (if (> try-count 4) false true))})

;; to handle a file with non-ascii filename, try :multipart-charset "UTF-8" and :multipart-mode BROWSER_COMPATIBLE
;; see also: https://stackoverflow.com/questions/3393445/international-characters-in-filename-in-mutipart-formdata
(import (org.apache.http.entity.mime HttpMultipartMode))

(client/post "http://example.org" {:multipart [{:content (clojure.java.io/file "日本語.txt")}]
                                   :multipart-mode HttpMultipartMode/BROWSER_COMPATIBLE
                                   :multipart-charset "UTF-8"} )

A word about flattening nested :query-params and :form-params maps. There are essentially three different ways to handle flattening them:

:ignore-nested-query-string
Do not handle nested query parameters specially, treat them as the exact text they come in as. Defaults to false.
:flatten-nested-form-params
Flatten nested (map within a map) :form-params before encoding it as the body. Defaults to false, meaning form params are encoded only x-www-form-urlencoded.
:flatten-nested-keys
An advanced way of specifying which keys having nested maps should be flattened. A middleware function checks the previous two options (:ignore-nested-query-string and :flatten-nested-form-params) and modifies this to be the list that will be flattened.

DELETE

(client/delete "http://example.com/resource")

Async HTTP Request

The new async HTTP request API is a Ring-style async API. All options for synchronous requests can be used in asynchronous requests. Starting an async request is easy, for example:
;; :async? in options map need to be true
(client/get "http://example.com"
            {:async? true}
            ;; respond callback
            (fn [response] (println "response is:" response))
            ;; raise callback
            (fn [exception] (println "exception message is: " (.getMessage exception))))

All exceptions thrown during the request will be passed to the raise callback.

Cancelling Requests

Calls to the http methods with :async true return an Apache BasicFuture that you can call .get or .cancel on. See the Javadocs for BasicFuture here. For instance:

(import '(java.util.concurrent TimeoutException TimeUnit))

(let [future (client/get "http://example.com/slow-url"
                         {:async true :oncancel #(println "request was cancelled")}
                         #(println :got %) #(println :err %))]
  (try
    (.get future 1 TimeUnit/SECONDS)
    (catch TimeoutException e
      ;; Cancel the request, it's taken too long
      (.cancel future true))))

Coercions

clj-http allows coercing the body of the request either before it is sent (input coercion), or after it’s received (output coercion) from the server.

Input coercion

;; body as a byte-array
(client/post "http://example.com/resources" {:body my-byte-array})

;; body as a string
(client/post "http://example.com/resources" {:body "string"})

;; :body-encoding is optional and defaults to "UTF-8"
(client/post "http://example.com/resources"
             {:body "string" :body-encoding "UTF-8"})

;; body as a file
(client/post "http://example.com/resources"
             {:body (clojure.java.io/file "/tmp/foo") :body-encoding "UTF-8"})

;; :length is optional for passing in an InputStream; if not
;; supplied it will default to -1 to signal to HttpClient to use
;; chunked encoding
(client/post "http://example.com/resources"
             {:body (clojure.java.io/input-stream "/tmp/foo")})

(client/post "http://example.com/resources"
             {:body (clojure.java.io/input-stream "/tmp/foo") :length 1000})

Output coercion

;; The default output is a string body
(client/get "http://example.com/foo.txt")

;; Coerce as a byte-array
(client/get "http://example.com/favicon.ico" {:as :byte-array})

;; Coerce as something other than UTF-8 string
(client/get "http://example.com/string.txt" {:as "UTF-16"})

;; Coerce as json
(client/get "http://example.com/foo.json" {:as :json})
(client/get "http://example.com/foo.json" {:as :json-string-keys})

;; Coerce as Transit encoded JSON or MessagePack
(client/get "http://example.com/foo" {:as :transit+json})
(client/get "http://example.com/foo" {:as :transit+msgpack})

;; Coerce as a clojure datastructure
(client/get "http://example.com/foo.clj" {:as :clojure})

;; Coerce as x-www-form-urlencoded
(client/post "http://example.com/foo" {:as :x-www-form-urlencoded})

;; Try to automatically coerce the output based on the content-type
;; header (this is currently a BETA feature!). Currently supports
;; text, json and clojure (with automatic charset detection)
;; clojure coercion requires "application/clojure" or
;; "application/edn" in the content-type header
(client/get "http://example.com/foo.json" {:as :auto})

;; Return the body as a stream
(client/get "http://example.com/bigrequest.html" {:as :stream})
;; Note that the connection to the server will NOT be closed until the
;; stream has been read

;; Return the body as a java.io.BufferedReader
(client/get "http://example.com/bigrequest.html" {:as :reader})
;; As above, the connection will remain open until the stream has been
;; read.  The reader will attempt to respect the server-specified charset,
;; if any, defaulting to UTF-8.

Output coercion with :as :json, :as :json-string-keys or :as :x-www-form-urlencoded, will only work with an optional dependency, see Optional Dependencies.

By default, JSON coercion is only applied when the response’s status is considered “unexceptional”. If the :unexceptional-status option is provided, then its value is a function which specifies what status codes are unexceptional. :unexceptional-status defaults to clj-http.client/unexceptional-status?.

If you would like to change under what conditions coercion is applied, you can send the :coerce option, which can be set to:

:always        ;; always json decode the body
:unexceptional ;; json decode when an HTTP response is considered unexceptional
:exceptional   ;; json decode when an HTTP response is considered exceptional

The :coerce setting defaults to :unexceptional.

Headers

clj-http’s treatment of headers is a little more permissive than the ring spec specifies.

Rather than forcing all request headers to be lowercase strings, clj-http allows strings or keywords of any case. Keywords will be transformed into their canonical representation, so the :content-md5 header will be sent to the server as “Content-MD5”, for instance. String keys in request headers, however, will be sent to the server with their casing unchanged.

Response headers can be read as keywords or strings of any case. If the server responds with a “Date” header, you could access the value of that header as :date, “date”, “Date”, etc.

If for some reason you require access to the original header name that the server specified, it is available by invoking (keys …) on the header map.

This special treatment of headers is implemented in the wrap-header-map middleware, which (like any middleware) can be disabled by using with-middleware to specify different behavior.

Query-string parameters

There are four different ways that query string parameters for array values can be generated, depending on what the resulting query string should look like, they are:

  • A repeating parameter (default)
  • Array style
  • Indexed array style
  • Comma separated style

Here is an example of the input and output for the :query-params parameter, controlled by the :multi-param-style option:

;; default style, with :multi-param-style unset
:a [1 2 3] => "a=1&a=2&a=3"
;; with :multi-param-style :array, a repeating param with array suffix
;; (PHP-style):
:a [1 2 3] => "a[]=1&a[]=2&a[]=3"
;; with :multi-param-style :indexed, a repeating param with array suffix and
;; index (Rails-style):
:a [1 2 3] => "a[0]=1&a[1]=2&a[2]=3"
;; with :multi-param-style :comma-separated, a param with comma-separated values
:a [1 2 3] => "a=1,2,3"

Meta Tag Headers

HTML 4.01 allows using the tag <meta http-equiv="..." /> and HTML 5 allows using the tag <meta charset="..." /> to specify a header that should be treated as an HTTP response header. By default, clj-http will ignore the body of the response (other than the regular output coercion), but if you need clj-http to parse the headers out of the body, you can use the :decode-body-headers option:

;; without decoding body headers (defaults to off):
(:headers (client/get "http://www.yomiuri.co.jp/"))
=> {"server" "Apache",
    "content-encoding" "gzip",
    "content-type" "text/html",
    "date" "Tue, 09 Oct 2012 18:02:41 GMT",
    "cache-control" "max-age=0, no-cache",
    "expires" "Tue, 09 Oct 2012 18:02:41 GMT",
    "etag" "\"1dfb-2686-4cba2686fb8b1\"",
    "pragma" "no-cache",
    "connection" "close"}

;; with decoding body headers, notice the content-type,
;; content-style-type and content-script-type headers:
(:headers (client/get "http://www.yomiuri.co.jp/" {:decode-body-headers true}))
=> {"server" "Apache",
    "content-encoding" "gzip",
    "content-script-type" "text/javascript",
    "content-style-type" "text/css",
    "content-type" "text/html; charset=Shift_JIS",
    "date" "Tue, 09 Oct 2012 18:02:59 GMT",
    "cache-control" "max-age=0, no-cache",
    "expires" "Tue, 09 Oct 2012 18:02:59 GMT",
    "etag" "\"1dfb-2686-4cba2686fb8b1\"",
    "pragma" "no-cache",
    "connection" "close"}

This can be used to have clj-http correctly interpret the body’s charset by using:

(client/get "http://www.yomiuri.co.jp/" {:decode-body-headers true :as :auto})
=> ;; correctly formatted :body (Shift_JIS charset instead of UTF-8)

Note that this feature is currently beta and uses Crouton to parse the body of the request. If you want to use this feature, you can include Crouton in addition to clj-http as a dependency like so:

(defproject foo "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.3.0"]
                 [clj-http "0.6.0"]
                 [crouton "1.0.0"]])

Note also that HEAD requests will not return a body, in which case this setting will have no effect.

clj-http will automatically disable the :decode-body-headers option.

Link Headers

clj-http parses any link headers returned in the response, and adds them to the :links key on the response map. This is particularly useful for paging RESTful APIs:

(:links (client/get "https://api.github.com/gists"))
=> {:next {:href "https://api.github.com/gists?page=2"}
    :last {:href "https://api.github.com/gists?page=22884"}}

Redirects

clj-http conforms its behaviour regarding automatic redirects to the RFC.

It means that redirects on status 301, 302, 307 and 308 are not redirected on methods other than GET and HEAD. If you want a behaviour closer to what most browser have, you can set :redirect-strategy to :lax in your request to have automatic redirection work on all methods by transforming the method of the request to GET.

Redirect Options:

:trace-redirects
If true, clj-http will enhance the response object with a list of redirected URLs with key: :trace-redirects.
:redirect-strategy
Sets the redirect strategy for clj-http. Accepts the following:

You may also pass in an instance of RedirectStrategy (in the :redirect-strategy key) if you want a behavior that’s not implemented.

Additionally, clj-http will attempt to validate that a redirect host is not invalid, you can disable this by setting :validate-redirects false in the request (the default is true)

NOTE: The options :force-redirects and :follow-redirects (present in clj-http 2.x are no longer used). You can use :graceful to mostly emulate the old redirect behaviour.

How to create a custom RedirectStrategy

As mentioned earlier, it’s possible to pass a custom instance of RedirectStrategy. The snippet below shows how to create a custom RedirectStrategy by wrapping the default strategy.
(def default-strategy org.apache.http.impl.client.DefaultRedirectStrategy/INSTANCE)

(def logging-redirect-strategy
  (reify org.apache.http.client.RedirectStrategy
    (getRedirect [this request response context]
      (println "attempting redirect...")
      (.getRedirect default-strategy request response context))
    (isRedirected [this request response context]
      (println "checking isRedirected")
      (.isRedirected default-strategy request response context))))

(client/get "https://httpbin.org/absolute-redirect/3" {:redirect-strategy logging-redirect-strategy})
;; this will output the following:
;;
;;   checking isRedirected
;;   attempting redirect...
;;   checking isRedirected
;;   attempting redirect...
;;   checking isRedirected
;;   attempting redirect...
;;   checking isRedirected

Cookies

Cookiestores

clj-http can simplify the maintenance of cookies across requests if it is provided with a cookie store.

(binding [clj-http.core/*cookie-store* (clj-http.cookies/cookie-store)]
  (client/post "http://example.com/login" {:form-params {:username "..."
                                                         :password "..."}})
  (client/get "http://example.com/secured-page")
  ...)

(The clj-http.cookies/cookie-store function returns a new empty instance of a default implementation of org.apache.http.client.CookieStore.)

This will allow cookies to only be written to the cookie store. Cookies from the cookie-store will not automatically be sent with future requests.

If you would like cookies from the cookie-store to automatically be sent with each request, specify the cookie-store with the :cookie-store option:

(let [my-cs (clj-http.cookies/cookie-store)]
  (client/post "http://example.com/login" {:form-params {:username "..."
                                                         :password "..."}
                                           :cookie-store my-cs})
  (client/post "http://example.com/update" {:body my-data
                                            :cookie-store my-cs}))

You can also use the get-cookies function to retrieve the cookies from a cookie store:

(def cs (clj-http.cookies/cookie-store))

(client/get "http://google.com" {:cookie-store cs})

(clojure.pprint/pprint (clj-http.cookies/get-cookies cs))
{"NID"
 {:domain ".google.com",
  :expires #<Date Tue Oct 02 10:12:06 MDT 2012>,
  :path "/",
  :value
  "58=c387....",
  :version 0},
 "PREF"
 {:domain ".google.com",
  :expires #<Date Wed Apr 02 10:12:06 MDT 2014>,
  :path "/",
  :value
  "ID=3ba...:FF=0:TM=133...:LM=133...:S=_iRM...",
  :version 0}}

Keystores, Trust-stores

You can also specify your own keystore/trust-store to be used:

(client/get "https://example.com" {:keystore "/path/to/keystore.ks"
                                   :keystore-type "jks" ; default: jks
                                   :keystore-pass "secretpass"
                                   :trust-store "/path/to/trust-store.ks"
                                   :trust-store-type "jks" ; default jks
                                   :trust-store-pass "trustpass"})

The :keystore/:trust-store values may be either paths to keystore files or KeyStore instances.

Exceptions

The client will throw exceptions on, well, exceptional status codes, meaning all HTTP responses other than #{200 201 202 203 204 205 206 207 300 301 302 303 304 307}. clj-http will throw a Slingshot Stone that can be caught by a regular (catch Exception e ...) or in Slingshot’s try+ block:

(client/get "http://example.com/broken")
=> ExceptionInfo clj-http: status 404  clj-http.client/wrap-exceptions/fn--583 (client.clj:41)
;; Or, if you would like the Exception message to contain the entire response:
(client/get "http://example.com/broken" {:throw-entire-message? true})
=> ExceptionInfo clj-http: status 404 {:status 404,
                                       :headers {"server" "nginx/1.0.4",
                                                 "x-runtime" "12ms",
                                                 "content-encoding" "gzip",
                                                 "content-type" "text/html; charset=utf-8",
                                                 "date" "Mon, 17 Oct 2011 23:15 :36 GMT",
                                                 "cache-control" "no-cache",
                                                 "status" "404 Not Found",
                                                 "transfer-encoding" "chunked",
                                                 "connection" "close"},
                                       :body "...body here..."}
   clj-http.client/wrap-exceptions/fn--584 (client.clj:42

;; You can also ignore HTTP-status-code exceptions and handle them yourself:
(client/get "http://example.com/broken" {:throw-exceptions false})
;; Or ignore an unknown host (methods return 'nil' if this is set to
;; true and the host does not exist:
(client/get "http://example.invalid" {:ignore-unknown-host? true})
;; Or customize the http statuses that will not throw:
(client/get "http://example.com/broken" {:unexceptional-status #(<= 200 % 299)})

(spacing added by me to be human readable)

How to use with Slingshot:

; Response map is thrown as exception obj.
; We filter out by status codes
(try+
  (client/get "http://example.com/broken")
  (catch [:status 403] {:keys [request-time headers body]}
    (log/warn "403" request-time headers))
  (catch [:status 404] {:keys [request-time headers body]}
    (log/warn "NOT Found 404" request-time headers body))
  (catch Object _
    (log/error (:throwable &throw-context) "unexpected error")
    (throw+)))

Decompression

By default, clj-http will add the {"Accept-Encoding" "gzip, deflate"} header to requests, and automatically decompress the resulting gzip or deflate stream if the Content-Encoding header is found on the response. If this is undesired, the {:decompress-body false} option can be specified:

;; Auto-decompression used: (google requires a user-agent to send gzip data)
(def h {"User-Agent" "Mozilla/5.0 (Windows NT 6.1;) Gecko/20100101 Firefox/13.0.1"})
(def resp (client/get "http://google.com" {:headers h}))
(:orig-content-encoding resp)
=> "gzip" ;; <= google sent response gzipped

;; and without decompression:
(def resp2 (client/get "http://google.com" {:headers h :decompress-body false})
(:orig-content-encoding resp2)
=> nil

If clj-http decompresses something, the “content-encoding” header is removed from the headers (because the encoding is no longer true). This allows clj-http to be used as a pass-through proxy with ring. The original content-encoding is available as :orig-content-encoding in the response map if auto-decompression is enabled.

Debugging

There are four debugging methods you can use:

;; print request info to *out*:
(client/get "http://example.org" {:debug true})

;; print request info to *out*, including request body:
(client/post "http://example.org" {:debug true :debug-body true :body "..."})

;; save the request that was sent in a :request key in the response:
(client/get "http://example.org" {:save-request? true})

;; save the request that was sent in a :request key in the response,
;; including the body content:
(client/get "http://example.org" {:save-request? true :debug-body true})

;; add an HttpResponseInterceptor to the request. This callback
;; is called for each redirects with the following args:
;; ^HttpResponse resp, HttpContext^ ctx
;; this allows low level debugging + access to socket.
;; see http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/HttpResponseInterceptor.html
(client/get "http://example.org" {:response-interceptor (fn [resp ctx] (println ctx))})

Logging

Finally, if you want to access the logging that the Apache client does internally, you can set up your dependencies to add the log4j2 libraries and configure the logging for clj-http. In order to do this, you’ll need to add

[org.apache.logging.log4j/log4j-api "2.11.0"]
[org.apache.logging.log4j/log4j-core "2.11.0"]
[org.apache.logging.log4j/log4j-1.2-api "2.11.0"]

To your project.clj and have a usable log4j2.properties. I have provided one in resources/log4j2.properties. Make sure to set:

rootLogger.level = debug

If you want to see debug information (or “trace” for trace logging). When you perform a request you should see something akin to this in the logs:

[2018-03-20T20:36:34,635][DEBUG][o.a.h.c.p.RequestAddCookies] CookieSpec selected: default
[2018-03-20T20:36:34,635][DEBUG][o.a.h.c.p.RequestAuthCache] Auth cache not set in the context
[2018-03-20T20:36:34,635][DEBUG][o.a.h.i.c.BasicHttpClientConnectionManager] Get connection for route {s}->https://example.com:443
[2018-03-20T20:36:34,636][DEBUG][o.a.h.i.c.DefaultManagedHttpClientConnection] http-outgoing-1: set socket timeout to 0
[2018-03-20T20:36:34,636][DEBUG][o.a.h.i.e.MainClientExec ] Opening connection {s}->https://example.com:443
[2018-03-20T20:36:34,644][DEBUG][o.a.h.i.c.DefaultHttpClientConnectionOperator] Connecting to example.com/10.0.0.1:443
[2018-03-20T20:36:34,644][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory] Connecting socket to example.com/10.0.0.1:443 with timeout 0
[2018-03-20T20:36:34,692][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory] Enabled protocols: [TLSv1, TLSv1.1, TLSv1.2]
[2018-03-20T20:36:34,693][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory] Enabled cipher suites:[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, ... etc ...]
[2018-03-20T20:36:34,693][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory] Starting handshake
[2018-03-20T20:36:34,841][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory] Secure session established
[2018-03-20T20:36:34,842][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory]  negotiated protocol: TLSv1.2
[2018-03-20T20:36:34,842][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory]  negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[2018-03-20T20:36:34,843][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory]  peer principal: CN=example.com
[2018-03-20T20:36:34,843][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory]  peer alternative names: [example.com, www.example.com]
[2018-03-20T20:36:34,843][DEBUG][o.a.h.c.s.SSLConnectionSocketFactory]  issuer principal: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
[2018-03-20T20:36:34,844][DEBUG][o.a.h.i.c.DefaultHttpClientConnectionOperator] Connection established 192.168.0.29:36792<->10.0.0.1:443
[2018-03-20T20:36:34,844][DEBUG][o.a.h.i.e.MainClientExec ] Executing request POST /post HTTP/1.1
[2018-03-20T20:36:34,844][DEBUG][o.a.h.i.e.MainClientExec ] Target auth state: UNCHALLENGED
[2018-03-20T20:36:34,844][DEBUG][o.a.h.i.e.MainClientExec ] Proxy auth state: UNCHALLENGED
[2018-03-20T20:36:34,845][DEBUG][o.a.h.headers            ] http-outgoing-1 >> POST /post HTTP/1.1
[2018-03-20T20:36:34,845][DEBUG][o.a.h.headers            ] http-outgoing-1 >> Connection: close
[2018-03-20T20:36:34,845][DEBUG][o.a.h.headers            ] http-outgoing-1 >> accept-encoding: gzip, deflate
[2018-03-20T20:36:34,845][DEBUG][o.a.h.headers            ] http-outgoing-1 >> Content-Length: 14
[2018-03-20T20:36:34,845][DEBUG][o.a.h.headers            ] http-outgoing-1 >> Content-Type: text/plain; charset=UTF-8
[2018-03-20T20:36:34,846][DEBUG][o.a.h.headers            ] http-outgoing-1 >> Host: example.com
[2018-03-20T20:36:34,846][DEBUG][o.a.h.headers            ] http-outgoing-1 >> User-Agent: Apache-HttpClient/4.5.5 (Java/9.0.1)
[2018-03-20T20:36:34,846][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "POST /post HTTP/1.1[\r][\n]"
[2018-03-20T20:36:34,846][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "Connection: close[\r][\n]"
[2018-03-20T20:36:34,846][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "accept-encoding: gzip, deflate[\r][\n]"
[2018-03-20T20:36:34,847][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "Content-Length: 14[\r][\n]"
[2018-03-20T20:36:34,847][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "Content-Type: text/plain; charset=UTF-8[\r][\n]"
[2018-03-20T20:36:34,847][DEBUG][o.a.h.wire               ] http-outgoing-1 >> "Host: example.com[\r][\n]"
etc etc it will go on forever and be very verbose

This provides both the data sent and received on the wire for debugging purposes.

I’ve also provided an example for changing the log level from clojure in examples/logging-apache-requests.clj.

Caching

clj-http supports Apache’s caching client, essentially it “provides an HTTP/1.1-compliant caching layer to be used with HttpClient–the Java equivalent of a browser cache.” (see the explanation in the apache docs). In order to use the cache, a reusable connection manager and http-client must be used.

An example of basic usage with the default options:

(let [cm (conn/make-reusable-conn-manager {})
      client (:http-client (http/get "http://example.com"
                                     {:connection-manager cm :cache true}))]
  (http/get "http://example.com"
            {:connection-manager cm :http-client client :cache true})
  (http/get "http://example.com"
            {:connection-manager cm :http-client client :cache true})
  (http/get "http://example.com"
            {:connection-manager cm :http-client client :cache true}))

You can build your own cache config by providing either a map of caching configuration options, or by providing a CacheConfig object, as seen below:

(let [cm (conn/make-reusable-conn-manager {})
      cache-config (core/build-cache-config
                    {:cache-config {:max-object-size 4096}})
      client (:http-client (http/get "http://example.com"
                                     {:connection-manager cm :cache true}))]
  (http/get "http://example.com"
            ;; Use the default cache config settings
            {:connection-manager cm :http-client client :cache true})
  (http/get "http://example.com"
            {:connection-manager cm :http-client client :cache true
             ;; Provide cache configuration options as a map
             :cache-config {:max-object-size 9152
                            :max-cache-entries 100}})
  (http/get "http://example.com"
            {:connection-manager cm :http-client client :cache true
             ;; Provide the cache configuration as a CacheConfig object
             :cache-config cache-config}))

In the response, clj-http provides the :cached key to indicate whether the response was cached, missed, etc:

nil
Caching was not used for this request
:CACHE_HIT
A response was generated from the cache with no requests sent upstream.
:CACHE_MISS
The response came from an upstream server.
:CACHE_MODULE_RESPONSE
The response was generated directly by the caching module.
:VALIDATED
The response was generated from the cache after validating the entry with the origin server.

Authentication

Basic Auth

(client/get "http://example.com/protected" {:basic-auth ["user" "pass"]})
(client/get "http://example.com/protected" {:basic-auth "user:pass"})

Digest Auth

(client/get "http://example.com/protected" {:digest-auth ["user" "pass"]})

NTLM Auth

(client/get "http://example.com/protected" {:ntlm-auth ["user" "pass" "host" "domain"]})

oAuth2

(client/get "http://example.com/protected" {:oauth-token "secret-token"})

Advanced Usage

Raw Request

A more general request function is also available, which is useful as a primitive for building higher-level interfaces:

(defn api-action [method path & [opts]]
  (client/request
    (merge {:method method :url (str "http://example.com/" path)} opts)))

Boolean options

Since 0.9.0, all boolean options can be expressed as either {:debug true} or {:debug? true}, with or without the question mark.

Persistent Connections

clj-http can use persistent connections to speed up connections if multiple connections are being used:

(with-connection-pool {:timeout 5 :threads 4 :insecure? false :default-per-route 10}
  (get "http://example.org/1")
  (post "http://example.org/2")
  (get "http://example.org/3")
  ...
  (get "http://example.org/999"))

For async request, you can use with-async-connection-pool

(with-async-connection-pool {:timeout 5 :threads 4 :insecure? false :default-per-route 10}
  (get "http://example.org/1" {:async? true} resp1 exce1)
  (post "http://example.org/2" {:async? true} resp2 exce2)
  (get "http://example.org/3" {:async? true} resp3 exce3)
  ...
  (get "http://example.org/999" {:async? true} resp999 exce999))

This is MUCH faster than sequentially performing all requests, because a persistent connection can be used instead creating a new connection for each request.

If you want to start an async request in the respond callback of an async request and reuse the pool context, just use reuse-pool.

(with-async-connection-pool {:timeout 5 :threads 4 :insecure? false :default-per-route 10}
  (get "http://example.org/1" {:async? true} resp1 exce1)
  (post "http://example.org/2"
        {:async? true}
        (fn [resp] (get "http://example.org/3"
                        (reuse-pool {:async? true} resp)
                        resp3 exce3))
        exce2))

There are many advanced options available when creating asynchronous connection pools that can be configured by passing an :io-config map in the connection manager parameters. It supports:

  • :connect-timeout
  • :interest-op-queued
  • :io-thread-count
  • :rcv-buf-size
  • :select-interval
  • :shutdown-grace-period
  • :snd-buf-size
  • :so-keep-alive
  • :so-linger
  • :so-timeout
  • :tcp-no-delay

See the docstring on with-async-connection-pool for more information about these options.

If you would prefer to handle managing the connection manager yourself, you can create a connection manager and specify it for each request:

(def cm (clj-http.conn-mgr/make-reusable-conn-manager {:timeout 2 :threads 3}))
(def cm2 (clj-http.conn-mgr/make-reusable-conn-manager {:timeout 10 :threads 1}))

(get "http://example.org/1" {:connection-manager cm2})
(post "http://example.org/2" {:connection-manager cm})
(get "http://example.org/3" {:connection-manager cm2})

;; Don't forget to shut it down when you're done!
(clj-http.conn-mgr/shutdown-manager cm)
(clj-http.conn-mgr/shutdown-manager cm2)

See the docstring on make-reusable-conn-manager for options and default values.

In the current version, pooled async request CANNOT specify connection manager.

Re-using HttpClient between requests

In some cases, you may want to re-use the same HttpClient object between requests, either so you don’t have to build it every time, or because you make some configuration change to the request. clj-http will return the built HTTP client in :http-client which you can then specify in subsequent requests (with :http-client). Note that in order to reuse the client a connection manager must be used.

;; Re-use the HttpClient clj-http builds for you:
(let [cm (conn/make-reusable-conn-manager {})
      resp (client/get "http://example.com" {:connection-manager cm})
      hclient (:http-client resp)]
  (client/get "http://example.com/1"
              {:connection-manager cm :http-client hclient})
  (client/get "http://example.com/2"
              {:connection-manager cm :http-client hclient})
  (client/get "http://example.com/3"
              {:connection-manager cm :http-client hclient}))

;; You can also build your own, using clj-http's helper or manually building it:
(let [cm (conn/make-reusable-conn-manager {})
      hclient (core/build-http-client {} false cm)]
  (client/get "http://example.com/1"
              {:connection-manager cm :http-client hclient})
  (client/get "http://example.com/2"
              {:connection-manager cm :http-client hclient})
  (client/get "http://example.com/3"
              {:connection-manager cm :http-client hclient}))

;; Async http clients may also be created and re-used:
(let [acm (conn/make-reuseable-async-conn-manager {})
      ahclient (core/build-async-http-client {} acm)]
  (client/get "http://example.com/1"
              {:connection-manager cm :http-client ahclient}
              handle-response handle-failure)
  (client/get "http://example.com/2"
              {:connection-manager cm :http-client ahclient}
              handle-response handle-failure)
  (client/get "http://example.com/3"
              {:connection-manager cm :http-client ahclient}
              handle-response handle-failure))

Proxies

A proxy can be specified by setting the Java properties: <scheme>.proxyHost and <scheme>.proxyPort where <scheme> is the client scheme used (normally ‘http’ or ‘https’). http.nonProxyHosts allows you to specify a pattern for hostnames which do not require proxy routing - this is shared for all schemes. Additionally, per-request proxies can be specified with the proxy-host and proxy-port options (this overrides http.nonProxyHosts too):

(client/get "http://example.com" {:proxy-host "127.0.0.1" :proxy-port 8118})

Proxy credentials can also be explicitly set as

(client/get "http://example.com" {:proxy-host "127.0.0.1" :proxy-port 8118 :proxy-user "proxy-user" :proxy-pass "superSecurePassword"})

You can also specify the proxy-ignore-hosts parameter with a list of hosts where the proxy should be ignored. By default this list is #{"localhost" "127.0.0.1"}.

A SOCKS proxy can be used by creating a proxied connection manager with clj-http.conn-mgr/make-socks-proxied-conn-manager. Then using that connection manager in the request.

For example if you wanted to connect to a local socks proxy on port 8081 you would:

(ns foo.bar
  (:require [clj-http.client :as client]
            [clj-http.conn-mgr :as conn-mgr]))

(client/get "https://google.com"
            {:connection-manager
             (conn-mgr/make-socks-proxied-conn-manager "localhost" 8081)})

If your SOCKS connection requires a keystore / trust-store, you can specify that too:

(ns foo.bar
  (:require [clj-http.client :as client]
            [clj-http.conn-mgr :as conn-mgr]))

(client/get "https://google.com"
            {:connection-manager
             (conn-mgr/make-socks-proxied-conn-manager "localhost" 8081
               {:keystore "/path/to/keystore.ks"
                :keystore-type "jks" ; default: jks
                :keystore-pass "secretpass"
                :trust-store "/path/to/trust-store.ks"
                :trust-store-type "jks" ; default jks
                :trust-store-pass "trustpass"})})

You can also store the proxied connection manager and reuse it later.

Custom Middleware

Sometime it is desirable to run a request with some middleware enabled and some left out, the with-middleware method provides this functionality:

(with-middleware [#'clj-http.client/wrap-method
                  #'clj-http.client/wrap-url
                  #'clj-http.client/wrap-exceptions]
  (get "http://example.com")
  (post "http://example.com/foo" {:body (.getBytes "foo")}))

To see available middleware, check the clj-http.client/default-middleware var, which is a vector of the default middleware that clj-http uses. clj-http.client/*current-middleware* is bound to the current list of middleware during request time.

Modifying Apache-specific features of the HttpClientBuilder and HttpAsyncClientBuilder

While clj-http tries to provide the features needed, there are times when it does not provide access to a parameter that you need. In these cases, you can use a couple of advanced parameters to provide arbitrary configuration functions to be run on the HttpClientBuilder by specifying :http-builder-fns and :async-http-builder-fns.

Each of these variables is a sequence of functions of two arguments, the http builder (HttpClientBuilder for :http-builder-fns and HttpAsyncClientBuilder for :async-http-builder-fns) and the request map.

;; A function that takes a builder and disables Apache's cookie management
(defun my-cookie-disabler [^HttpClientBuilder builder
                           request]
  (when (:disable-cookies request)
    (.disableCookieManagement builder)))

;; The functions to modify the builder are passed in
(http/post "http://www.example.org" {:http-builder-fns [my-cookie-disabler]
                                     :disable-cookies true})

The functions are run in the order they are passed in (inside a doseq).

By specifying :http-client-builder, your own instance of HttpClientBuilder will be used. A supplied HttpClientBuilder which sets the connection manager, redirect strategy, retry handler, route planner, cache, or cookie spec registry may find these overridden by clj-http’s :connection-manager, :redirect-strategy, :retry-handler, :cache, or :cookie-policy-registry or :cookie-spec, respectively.

Incrementally JSON Parsing

cheshire supports incrementally parsing JSON using lazy sequences. This approach can useful for processing large top-level JSON arrays because it doesn’t require upfront work consuming the entire stream.
(require '[cheshire.core :as json])

(defn print-all-pokemon-names [pokemons]
  (for [pokemon pokemons]
    (println (get-in pokemon [:name :english]))))

(let [url "https://raw.githubusercontent.com/fanzeyi/pokemon.json/master/pokedex.json"
      response (get url {:as :reader})]
  (with-open [reader (:body response)]  ; closes the underlying connection when we're done
    (let [pokemons (json/parse-stream reader true)]
      ; You must perform all reads from the stream inside `with-open`,
      ; any , any lazy
      (doall (print-all-pokemon-names pokemons)))))

Keep in mind that the reader object wraps a HTTP connection. The user needs to be aware of two things:

  1. The user should close the reader after processing the stream, otherwise the underlying HTTP Connection may leak and create subtle bugs. Clojure’s with-open is useful here.
  2. You should realize any lazy sequences before closing the connection. Use doall or transducers to prevent bugs from lazy IO. See Clojure Don’ts: Lazy Effects.

In previous versions of clj-http (<= 3.10.0), clj-http defaulted to lazily parsing JSON, but this was slow and also confused users who didn’t expect laziness.

DNS Resolution

Users may add their own DNS resolver function to override the default DNS Resolver. This is useful in situations where you are unable to change the name to IP Address mapping. It is analogous to the --resolve flag present in curl. This example uses org.apache.http.impl.conn.InMemoryDnsResolver to resolve example.com to IP Address 127.0.0.1.

(client/get "https://example.com" {:dns-resolver (doto (InMemoryDnsResolver.)
                                                   (.add "example.com" (into-array[(InetAddress/getByAddress (byte-array [127 0 0 1]))])))})

This option is supported for all of the connection managers.

The dns-resolver can be any instance of DnsResolver. Here is an example of a custom implementation that attempts to look up the hostname in the supplied map and falls back to the default SystemDnsResolver if not found. Note how IPV6 addresses are specified.

(defn custom-dns-resolver
  [host-map]
  (let [system-dns-resolver (org.apache.http.impl.conn.SystemDefaultDnsResolver.)]
    (reify
      org.apache.http.conn.DnsResolver
      (^"[Ljava.net.InetAddress;" resolve [this ^String host]
       (if-let [address (get host-map host)]
         (into-array [(java.net.InetAddress/getByAddress host (byte-array address))])
         (.resolve system-dns-resolver host))))))
       
(client/get "https://example.com" {:dns-resolver (custom-dns-resolver {"example.com" [127 0 0 1]
                                                                        "www.google.com" [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1]})})

Development

Please send a pull request or open an issue if you have any problems. See CONTRIBUTING.md for more information.

Faking Responses

If you need to fake clj-http responses (for things like testing and such), check out the clj-http-fake library.

Optional Dependencies

In 2.0.0+ clj-http’s optional dependencies at excluded by default, in order to use the features you will need to add them to your project.clj file.

clj-http currently has four optional dependencies, cheshire, crouton, tools.reader and ring/ring-codec. Any number of them may be included by adding them with the clj-http dependency in your project.clj:

;; optional dependencies
[cheshire] ;; for :as :json
[crouton] ;; for :decode-body-headers
[org.clojure/tools.reader] ;; for :as :clojure
[ring/ring-codec] ;; for :as :x-www-form-urlencoded
[com.cognitect/transit-clj] ;; for transit support

Prior to 2.0.0, you can exclude the dependencies and clj-http will work without them.

clj-http-lite

Like clj-http but need something more lightweight without as any external dependencies? Check out clj-http-lite for a project that can be used as a drop-in replacement for clj-http.

Troubleshooting

VerifyError class org.codehaus.jackson.smile.SmileParser overrides final method getBinaryValue…

This is actually caused by your project attempting to use clj-json and cheshire in the same classloader. You can fix the issue by either not using clj-json (and thus choosing cheshire), or specifying an exclusion for clj-http in your project like this:

(defproject foo "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.3.0"]
                 [clj-http "0.3.4" :exclusions [cheshire]]])

Note that if you exclude cheshire, json decoding of response bodies and json encoding of form-params cannot happen, you are responsible for your own encoding/decoding.

As of clj-http 0.3.5, you should no longer see this, as Cheshire 3.1.0 and clj-json can now live together without causing problems.

NoHttpResponseException … due to stale connections**

Persistent connections kept alive by the connection manager become stale: the target server shuts down the connection on its end without HttpClient being able to react to that event, while the connection is being idle, thus rendering the connection half-closed or ‘stale’.

This can be solved by using (with-connection-pool) as described in the ‘Using Persistent Connection’ section above.

Tests

To run the tests:

$ lein deps
$ lein test

Run all tests (including integration):
$ lein test :all

Run tests against all clojure versions
$ lein all test
$ lein all test :all

Testimonials

With over three million downloads, clj-http is a widely used, battle-tested clojure library. It is also included in other libraries (like database clients) as a low-level http wrapper.

Libraries using clj-http:

Libraries inspired by clj-http:

Other Libraries Providing Middleware

aws-sig4
a pure clojure implementation of AWS v4 signature request signing as middleware

(feel free to open a PR or issue if you’d like to add middleware here)

License

Released under the MIT License: http://www.opensource.org/licenses/mit-license.php

clj-http's People

Contributors

carld avatar cemerick avatar dakrone avatar dankaplanses avatar djjolicoeur avatar drewr avatar dskrvk avatar evanhahn avatar frenchy64 avatar jimbarritt avatar joegallo avatar joelittlejohn avatar maxnoel avatar mesjj avatar michaelklishin avatar mknoszlig avatar mmcgrana avatar ngrunwald avatar oliyh avatar pmonks avatar priyatam avatar propan avatar r0man avatar roman avatar rymndhng avatar senior avatar technomancy avatar weavejester avatar wilkerlucio avatar zk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

clj-http's Issues

Provide a way to do multipart/form-data

I ran into a bit of trouble while writing my Github API library. The Github downloads API requires you to upload files to AWS, and aws requires multipart form data. There doesn't seem to be a way to do this in clj-http.

POST retry behavior is not configurable

I'm testing a server by sending requests to it through clj-http. When doing a multipart post, I get this output

Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request: The target server failed to respond
Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: Retrying request
Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request: The target server failed to respond
Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: Retrying request
Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request: The target server failed to respond
Apr 17, 2012 1:18:26 PM org.apache.http.impl.client.DefaultRequestDirector execute
INFO: Retrying request

The fact that my server isn't responding is the issue I'm trying to fix, but the fact that the request is being sent three times muddles the process up. It would be nice if this could be disabled.

Extra 'cookie' header is included in request with cookie store

When using the cookie-store, I get an extra 'cookie' (notice lowercased) header set in my second request.

GET http://aspectoweb.local/ShowQuestion.aspx?rid=d4cf71ec-5224-42da-b2b6-9a92c5aacfd2 HTTP/1.1
Connection: close
accept-encoding: gzip, deflate
cookie:
Host: aspectoweb.local
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.2.2 (java 1.5)
Cookie: ASP.NET_SessionId=zbf1npc5f4q1c21a3cang551

This apparently causes problems (at least with ASP.NET), so the cookie is not recognized.

If I replay the request without the extra 'cookie:' header, everything works fine.

Method that I'm using to fetch (set up with Fiddler as proxy.. experimented with redirects as well)

(defn- fetch-url [url cookies]
  (let [request (client/get url {:cookie-store cookies :follow-redirects true :response-interceptor (fn [resp ctx] (println ctx)) :proxy-host "127.0.0.1" :proxy-port 8888})
        content (parse-as-string request)]
  request))

How to send body map as JSON?

This section doesn't tell you how to send a body map that will be converted to JSON automatically.

https://github.com/dakrone/clj-http#input-coercion

(client/post "http://localhost:5000/v1/categories" {:body {:name "Computers"} :content-type :json})

gives me error:

CompilerException java.lang.RuntimeException: Unable to resolve symbol: => in this context, compiling (NO_SOURCE_PATH:1) 

ClassCastException clojure.lang.PersistentArrayMap cannot be cast to [B  clj-http.core/request (core.clj:220)

I have also tried

(client/post "http://localhost:5000/v1/categories" {:body {:name "Computers"} :as :json})

with the same error.

How do I tell the library to convert it to JSON?

Evolution suggestion: have wrap-redirects store a vector of traversed uri in the response

add a key like :trace-redirects in the response containing the ordered list of traversed uris. This would allow clients to know what was the final uri fetched more easily than now (I think the only way is to set :save-request? and check the url inside the req). It could also be very useful for caching purpose (knowing all the uris which are equivalent to the terminal one).
If you're interested, I can write the patch.

Client always follows redirects

There's no way to set the flag on the Apache client that tells it not to follow redirects; instead it appears that they're always followed. I want to handle a 302 response myself, rather than getting the result of the redirected request.

Proxy functionality doesn't work with a SOCKS Proxy

I've got a local SOCKS proxy running on port 9999. When I pass :proxy-host "127.0.0.1", :proxy-port 9999 in the options map, then an "org.apache.http.NoHttpResponseException: The target server failed to respond" is thrown.

URL encoding of paths

This is not a bug report, just a thought to start a conversation.

In several of ClojureWerkz libraries that use clj-http we ended up doing URL encoding of paths. I am curious if this is something that clj-http should provide.

Are there any reasons why clj-http or Apache HTTP components don't do automatic URL encoding for paths or offer it as an option?

Provide a means of capturing the request

I'm using clj-http in request testing a service. Through the underlying HTTPClient4, it'd be great if the base get/post/etc methods could provide a hook for getting info about the request (URL + headers) for reporting during the testing - maybe a switch to return both request + response data? Probably there's a better clojure idiom that fits here. The alternative is to setup an embedded proxy (which I haven't had much luck with, at least using browsermob-proxy).

Automatic encoding detection fails on certain urls.

Hey,
Automatic encoding detection for webpages fails on a number of asian pages like this one.

(:require [clj-http.client :as http ])

(http/get "http://www.yomiuri.co.jp/" {:as :auto})

The reason is that for some reason clojure downloads the charset line in the source in the following way:
content="text/html; charset=Shift_JIS"
(This is from the output of of the command I issued above)

The backslash after "Shift_JIS" shouldn't be there and is preventing the correct pattern matching. (Lines 203-232 of client.clj). A simple fix would be to match the backslash in something like:
(?)? So that it is ignored in the re-find. I could writer a simple patch if you agree to that approach. If not could you suggest for a more idiomatic way to solve the problem?

wrap-redirects should redirect POST responses too

Redirecting after a POST is very common, but wrap-redirects only follows redirects on GET and HEAD requests (and only follows 303 responses on HEADs, which seems very odd). Reading the relevant spec sections, it seems that any valid 3xx response code should be followed, with the :method always altered to a :get.

This is technically contrary to a couple of RFCs, but the spec explicitly says:

However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method.

In general, I'd rather track what browsers (and API clients) do in general — or at least have an option to :redirect-posts.

Thoughts?

Allow to set maximum number of redirections in wrap-redirects

Many pages on the web have through ill-intent or plain negligence cyclic redirections which will stall the client if it follows them blindly. Allowing to specify a maximum number of redirections to follow makes the process optionally more robust. The patch is backward-compatible and comes with a test.

conflicts with clj-json

clj-http 0.3.x conflicts with clj-json.

I don't know which library is bad, but clj-http 0.2.7 doesn't conflict.

How to reproduce:

$ lein new foo
$ cd foo
$ vim project.clj
(defproject foo "1.0.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.3.0"]
                 [clj-http "0.3.1"]
                 [clj-json "0.5.0"] ])
$ vim src/foo/core.clj
(ns foo.core
  (:require [clj-http.client :as client]) )

(defn -main [])
$ lein deps
$ lein run -m foo.core
Exception in thread "main" java.lang.RuntimeException: java.lang.VerifyError: class org.codehaus.jackson.smile.SmileParser overrides final method getBinaryValue.(Lorg/codehaus/jackson/Base64Variant;)[B
        at clojure.lang.Util.runtimeException(Util.java:165)
        at clojure.lang.Compiler.eval(Compiler.java:6476)
        at clojure.lang.Compiler.eval(Compiler.java:6455)
(..snip..)

Make error messages clearer

When executing a GET operation I got this from a Ring server:

org.apache.http.client.ClientProtocolException                                  
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:822)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
    at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
    at clj_http.core$request.invoke(core.clj:180)                               
    at clojure.lang.Var.invoke(Var.java:365)                                    
    at clj_http.client$wrap_query_params$fn__952.invoke(client.clj:137)         
    at clj_http.client$wrap_user_info$fn__961.invoke(client.clj:162)            
    at clj_http.client$wrap_url$fn__975.invoke(client.clj:184)                  
    at clj_http.client$wrap_redirects$fn__913.invoke(client.clj:46)             
    at clj_http.client$wrap_decompression$fn__918.invoke(client.clj:63)         
    at clj_http.client$wrap_input_coercion$fn__929.invoke(client.clj:88)        
    at clj_http.client$wrap_output_coercion$fn__924.invoke(client.clj:75)       
    at clj_http.client$wrap_exceptions$fn__906.invoke(client.clj:32)            
    at clj_http.client$wrap_basic_auth$fn__956.invoke(client.clj:152)           
    at clj_http.client$wrap_accept$fn__938.invoke(client.clj:109)               
    at clj_http.client$wrap_accept_encoding$fn__943.invoke(client.clj:122)      
    at clj_http.client$wrap_content_type$fn__934.invoke(client.clj:100)         
    at clj_http.client$wrap_form_params$fn__971.invoke(client.clj:179)          
    at clj_http.client$wrap_method$fn__966.invoke(client.clj:167)               
    at clj_http.cookies$wrap_cookies$fn__752.invoke(cookies.clj:114)            
    at clj_http.client$get.doInvoke(client.clj:234)                             
    at clojure.lang.RestFn.invoke(RestFn.java:424)
    ...more...

It should clearly say what was it expecting and what did it find instead. Without that, it's hard to debug what's wrong.

Better :body debugging

Currently, when passing {:debug true} or {:save-request? true}, the :body that is returned looks like:

:body #<StringEntity org.apache.http.entity.StringEntity@714c7f58>

There should be an easier way to debug the bodies of requests.

Cookie parsing corrupts cookies with '+'s in them

I'm getting an encoded signature back in a cookie. The actual value received (from tcpdump) is:

{"identity": "{\"realm\": \"usdev150\", \"value\": \"{\\\"customer\\\": \\\"root\\\", \\\"realm\\\": \\\"usdev150\\\", \\\"entity_type\\\": \\\"user\\\", \\\"expires\\\": 1341591987.901052, \\\"user\\\": \\\"/root/root\\\", \\\"groups\\\": [\\\"/root\\\"]}\", \"signature\": \"APKYYWYI2X3VD0twdWneg+fGNt8yuyyaDbACoXhIkjVJlwB4Vnm4UqLvbTvBN4IpFZUSFK9h3uGEND9ndyzuLoDtdN/K6T2NkhxOECU7YKZ9XyLlVB0wA8Pv57+TsAYpTF7Jhhdq4YYMzvdBNeskhpbig1trFlP42hYp6R1BpBSnLRr3+cmlnuUfpNqEFze6HJgsZgHMHKB0CSn/NSTReH4sAIRJLrtNW9QRz7hlbUY0uTZejkuLlH+EQIZJDkVAPiN1owwMaPXU1KR49BJYuxH23JXRELSGy2wCql2YK9Fvhi/DXqMMwUw/RBAwVYwog3+jUY9Gv/WF1emEGM64cBnwTQ6C\"}"}

while the value I get in the debug output is:

{\"identity\": \"{\\\"realm\\\": \\\"usdev150\\\", \\\"value\\\": \\\"{\\\\\\\"customer\\\\\\\": \\\\\\\"root\\\\\\\", \\\\\\\"realm\\\\\\\": \\\\\\\"usdev150\\\\\\\", \\\\\\\"entity_type\\\\\\\": \\\\\\\"user\\\\\\\", \\\\\\\"expires\\\\\\\": 1341591987.901052, \\\\\\\"user\\\\\\\": \\\\\\\"/root/root\\\\\\\", \\\\\\\"groups\\\\\\\": [\\\\\\\"/root\\\\\\\"]}\\\", \\\"signature\\\": \\\"APKYYWYI2X3VD0twdWneg fGNt8yuyyaDbACoXhIkjVJlwB4Vnm4UqLvbTvBN4IpFZUSFK9h3uGEND9ndyzuLoDtdN/K6T2NkhxOECU7YKZ9XyLlVB0wA8Pv57 TsAYpTF7Jhhdq4YYMzvdBNeskhpbig1trFlP42hYp6R1BpBSnLRr3 cmlnuUfpNqEFze6HJgsZgHMHKB0CSn/NSTReH4sAIRJLrtNW9QRz7hlbUY0uTZejkuLlH EQIZJDkVAPiN1owwMaPXU1KR49BJYuxH23JXRELSGy2wCql2YK9Fvhi/DXqMMwUw/RBAwVYwog3 jUY9Gv/WF1emEGM64cBnwTQ6C\\\"}\"}

Apart from the escaping from printing, you can see that each time there is a '+' character in the original value, I receive a space character.

302 redirects not working?

=> (client/get "http://google.com")
{:cookies {"PREF" {:domain ".google.com", ... }, :status 302, :headers {"x-xss-protection" "1; mode=block", "server" "gws", "x-frame-options" "SAMEORIGIN", "content-type" "text/html; charset=UTF-8", "date" "Fri, 28 Oct 2011 16:05:00 GMT", "cache-control" "private", "location" "http://www.google.co.uk/", "content-length" "221", "connection" "close"}, :body "<HTML><HEAD><meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\">\n<TITLE>302 Moved</TITLE></HEAD><BODY>\n<H1>302 Moved</H1>\nThe document has moved\n<A HREF=\"http://www.google.co.uk/\">here</A>.\r\n</BODY></HTML>\r\n"}

=> (client/get "http://www.nytimes.com:80/2011/10/29/business/the-spotlight-now-shines-on-italy-common-sense.html")
{:cookies {"NYT-S" {:domain ".nytimes.com", :expires #<Date Sun Nov 27 16:18:10 GMT 2011>, :path "/", :value "0Mzh9PJwQ663rDXrmvxADeHCyZ5RAjhv6MdeFz9JchiAIUFL2BEX5FWcV.Ynx4rkFI", :version 0}}, :status 302, :headers {"date" "Fri, 28 Oct 2011 16:18:10 GMT", "server" "Apache/2.2.3 (CentOS)", "location" "http://www.nytimes.com:80/2011/10/29/business/the-spotlight-now-shines-on-italy-common-sense.html?_r=1", "content-length" "0", "connection" "close", "content-type" "text/html; charset=UTF-8"}, :body ""}

Decompression not working properly

In 0.2.1, decompression doesn't seem to be working right:

user=> (use 'clj-http.client) 
WARNING: get already refers to: #'clojure.core/get in namespace: user, being replaced by: #'clj-http.client/get
nil
user=> (get "http://api.clojuredocs.org/examples/println")
EOFException Unexpected end of ZLIB input stream  java.util.zip.InflaterInputStream.fill (InflaterInputStream.java:223)

This is in a fresh clojure 1.3 REPL.

I discovered this while updating your cd-client to 1.3 and 0.2.1 of clj-http. This only happens with 0.2.1. It works fine with the older version.

Wrong Content-Length header for POST request

clj-http seems to have an issues with generating headers for POST requests:

  • Content-Length is always set to 0
  • Content-Type is not set at all (should be "application/x-www-form-urlencoded" for URL-encoded form parameters)

Tested with clj-http-0.3.3 and this client code:

(client/post "http://localhost:8888/test" {:form-params {:foo "bar"}})

persistent connections

Hi,
clj-http appears to be creating and destroying a connection for each request. This is fine in many circumstances but when dealing with an API persistent connections are preffered for time and resource savings. Are persistent connections a non-objective for clj-http or is it something that you would like to see happen?

A simple approach would be to provide a http-client constructor in core and allow the resulting client to be passed into the request fn. (If no client is passed in the current behvaviour would be preserved and a new connection would be created and closed.) Special care would have to be given for when a connection times out so it can be reestablished. The client could be wrapped in an atom to provide thread safety. I haven't thought too much about it but the appraoch seems reasonable... WDYT?

Thanks!

wrap-exceptions does not throw Exceptions (if wrapped in try+)

I just discovered, much to my surprise, that my code that has a try+/catch block with a (catch Exception e...) at the end does not catch "403" exceptions thrown by wrap-exceptions. It does catch everything else, e.g. other exceptions, just not those thrown by wrap-exceptions.

This is at least unintuitive and I'm not quite sure what is the right way to go, but: I filed an issue with slingshot (scgilardi/slingshot#24) and now I'm thinking whether it is a good idea for a library such as clj-http to throw exceptions using throw+.

I think (I'm not 100% certain, though) that while using try+/throw+ within the library is fine, exceptions that do not get caught should follow the standard Java conventions. I did not expect to see throw+ in clj-http and I had to look at the source code to see it.

generate-query-string doesn't escape all params

The following renders an error:

(clj-http.core/generate-query-string {
:timestampBegin "2012-11-26 10:00:00 UTC"
:timestampEnd "2012­11­27 10:00:00 UTC"})

where the {} is the query-params. It gives the following result:

"timestampBegin=2012-11-26+10%3A00%3A00+UTC&timestampEnd=2012%C2%AD11%C2%AD27+10%3A00%3A00+UTC"

Please note that the dashes in timestampBegin is not correctly URL-encoded, on the contrary to timestampEnd. This must be a bug.

Expected behaviour is that all params are correctly URLencoded.

change commons codec dependency to 1.3 for Android

Can the project.clj dependency for commons codec be changed to 1.3 instead of 1.5? This won't make a practical difference as the only method out of that library that clj-http uses also exists in 1.3.

However pulling in commons codec 1.5 into any project by virtue of including clj-http can lead to compile-time vs. run-time conflicts on Android as Android contains a built-in version of commons codec 1.3 (as per source here)

Basic auth params in URL aren't picked up by wrap-request handlers

Because of the ordering in wrap-request, a URL like http://user:password@host:port/path will not have basic auth info extracted out of the URL. In order for this to work, the -> form in wrap-request must have wrap-url after wrap-user-info, and wrap-user-info after wrap-basic-info.

Is this unintentional, or are we supposed to just put :basic-auth keys directly in the request map?

NullPointerException when requesting headers from a buggy server

(http/head "http://www.payback.pl/" {:throw-exceptions false})


  [Thrown class java.lang.NullPointerException]

Backtrace:
  0: java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:89)
  1: clj_http.util$gunzip.invoke(util.clj:39)
  2: clojure.lang.AFn.applyToHelper(AFn.java:163)
  3: clojure.lang.AFn.applyTo(AFn.java:151)
  4: clojure.core$apply.invoke(core.clj:542)
  5: clj_http.client$update.doInvoke(client.clj:11)
  6: clojure.lang.RestFn.invoke(RestFn.java:446)
  7: clj_http.client$wrap_decompression$fn__3119.invoke(client.clj:66)
  8: clj_http.client$wrap_input_coercion$fn__3130.invoke(client.clj:87)
  9: clj_http.client$wrap_output_coercion$fn__3125.invoke(client.clj:74)
 10: clj_http.client$wrap_basic_auth$fn__3157.invoke(client.clj:149)
 11: clj_http.client$wrap_accept$fn__3139.invoke(client.clj:109)
 12: clj_http.client$wrap_accept_encoding$fn__3144.invoke(client.clj:121)
 13: clj_http.client$wrap_content_type$fn__3135.invoke(client.clj:100)
 14: clj_http.client$wrap_form_params$fn__3173.invoke(client.clj:175)
 15: clj_http.client$wrap_method$fn__3168.invoke(client.clj:164)
 16: clj_http.cookies$wrap_cookies$fn__3073.invoke(cookies.clj:114)
 17: clj_http.client$head.doInvoke(client.clj:235)
 18: clojure.lang.RestFn.invoke(RestFn.java:424)

Now, this is a misbehaving server, as a quick test with curl shows:

curl -X HEAD -v http://www.payback.pl/
* About to connect() to www.payback.pl port 80 (#0)
*   Trying 194.64.230.139... connected
* Connected to www.payback.pl (194.64.230.139) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-apple-darwin10.3.0) libcurl/7.20.1 OpenSSL/0.9.8r zlib/1.2.5
> Host: www.payback.pl
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Thu, 29 Sep 2011 08:43:04 GMT
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=459FE9EBA627536F8CC0319005320D88; Path=/pb
< Set-Cookie: _tracking_cookie=20110929104304927_51U6I6; Expires=Fri, 28-Sep-2012 08:43:04 GMT; Path=/
< Content-Type: text/html;charset=utf-8
< Content-Language: de-DE
< Content-Length: 28704
< Vary: Accept-Encoding,User-Agent
< Cache-Control: no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform, private
< Pragma: no-cache
< Set-Cookie: www-cookie=22088202.64545.0000; path=/
< 
* transfer closed with 28704 bytes remaining to read
* Closing connection #0
curl: (18) transfer closed with 28704 bytes remaining to read

but I would expect clj-http to do something more reasonable than throw an exception, especially since I've requested that exceptions not be thrown. Parse the partial reply? Return nil? Return a result map with :status set to nil? I don't really know what the best choice is.

Response :headers is missing Content-Length

When I make this request via cURL, I see that my server is returning the response header Content-Length:

HTTP/1.1 200 OK
Date: Fri, 05 Oct 2012 03:07:10 GMT
Vary: accept-charset, accept
Content-Type: text/html;charset=UTF-8
Content-Length: 939
Server: Jetty(7.6.1.v20120215)

When I make the same request with clj-http 0.5.5, using Clojure 1.4 and Java 7, Content-Length is missing:

my-ns.core=> (:headers (client/get "http://localhost:3000/terms" {:accept "*/*"}))
{"date" "Fri, 05 Oct 2012 03:10:45 GMT", "vary" "accept-encoding, accept-charset, accept", "content-type" "text/html;charset=UTF-8", "connection" "close", "server" "Jetty(7.6.1.v20120215)"}

Turn off exceptions on non-200/300 codes

The library makes an assumption that a non-200/300 code is something that should be handled using exceptions. Better to return the reponse map and let the developer's application decide whether or not an exception is needed. The current behavior forces a developer to use try/catch blocks defensively wherease the proposed behavior would allow the application to make simpler calls with clj-http.

Zero Content-Length in get request gets 400 Bad Request from some servers

Hi,
client/get sometimes yields a 400 error from some sites. When I try to reproduce this using openConnection on a java.net.URL or the Apache HttpClient directly, this doesn't happen. The only difference I see in the headers sent is the addition of the Content-Length header which is set to 0 in the clj-http request. Not all servers respond with a 400 though. One that consistently does is http://thepiratebay.se.

See: http://stackoverflow.com/questions/13783892/zero-content-length-in-get-request-gets-400-bad-request-from-lighttpd-clj-http

What is forcing the addition of the said header? Any way to prevent this?

Turning off org.apache.http logging?

When I run code using clj-http in the repl, I'm seeing a ton of logging messges like...
DEBUG pool-1-thread-18 20111109 095547,513 org.apache.http.impl.conn.SingleClientConnManager ] Releasing connection org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter@4ea6c971
DEBUG pool-1-thread-18 20111109 095547,513 org.apache.http.impl.conn.SingleClientConnManager ] Released connection open but not reusable.
DEBUG pool-1-thread-18 20111109 095547,513 org.apache.http.impl.conn.DefaultClientConnection ] Connection shut down

I haven't passed in any options that would turn these on - only using :throw-exceptions false
How can I turn these off?

with-connection-pool throws error if the request is made in another agent

Whenever I send a request message to a different agent in the body of a with-connection-pool macro, I get a "java.lang.IllegalStateException: Connection pool shut down"

Example:

(def tst-agnt (agent nil))

(http/with-connection-pool {:threads 1} (send tst-agnt (fn _)))

using [clj-http "0.5.0"] , [org.clojure/clojure "1.4.0"]

Thanks

gzip decoding doesn't work

I am using [clj-http "0.5.0"]

The output of

(require '[clj-http.client :as client])

(def headers {"User-Agent" "Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0.1"
"Accept" "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,text/png,/;q=0.5"
"Accept-Language" "en-us,en;q=0.5"
"Connection" "keep-alive"
"Content-type" "application/x-www-form-urlencoded"
"Accept-Encoding" "gzip, deflate"})

(client/get "http://www.google.com" {:headers headers})

are nonsensical characters.

Make request functions dynamic

It'd be helpful if the get, head, post, put, delete functions in client.clj were marked ^:dynamic; in Clojure 1.3, variables need to be explicitly marked with ^:dynamic to be rebindable.

Using the clojure.core/binding macro to replace those functions allows using different HTTP libraries during testing. In this case, I have test code written to use clj-http, and I am also using The Grinder, a load testing tool that has its own instrumented HTTP library. Via rebinding, the same test code can be run from the REPL using clj-http when manual testing is needed and from The Grinder using its HTTP library when load testing is needed.

Currently, I need to write a ^:dynamic wrapper function around my clj-http calls to make this work. It'd be better if those functions could be rebound directly.

Eliminate Reflection Warnings

In my project.clj file I typically include :warn-on-reflection true, which revealed the following warnings for clj-http:

Reflection warning, clj_http/cookies.clj:65 - call to parse can't be resolved.
Reflection warning, clj_http/cookies.clj:94 - call to formatCookies can't be resolved.
Reflection warning, clj_http/cookies.clj:96 - reference to field getValue can't be resolved.
Reflection warning, clj_http/core.clj:67 - call to org.apache.http.conn.scheme.Scheme ctor can't be resolved.
Reflection warning, clj_http/core.clj:120 - call to java.lang.Integer ctor can't be resolved.
Reflection warning, clj_http/core.clj:122 - call to java.lang.Integer ctor can't be resolved.
Reflection warning, clj_http/core.clj:140 - call to org.apache.http.impl.client.DefaultHttpClient ctor can't be resolved.

Would be nice if you could eliminate them, and also include the warning option in your project.clj file.

Better error messages for bad requests

When I'm debugging a request that's getting a 400 Bad Request header, or a 401 Authorization Required from the server, it's really helpful to actually be able to read the response body, or view the headers being sent to the server, so I can debug what's wrong with the query. I know clj-http is a wrapper on top of an Apache library, but I can't figure out how to get the response body on a 400 bad request through the clj-http interface.

I'd appreciate some help; I'm new to Clojure, I've never used this library before and a similar POST request using curl is working fine.

Reflection warnings

Against Clojure 1.3.0:

 [exec] Reflection warning, clj_http/cookies.clj:29 - reference to field getName can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:36 - reference to field getPath can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:34 - reference to field getDomain can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:31 - reference to field getComment can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:37 - reference to field getPorts can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:37 - reference to field getPorts can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:35 - reference to field getExpiryDate can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:35 - reference to field getExpiryDate can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:40 - reference to field getVersion can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:32 - reference to field getCommentURL can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:33 - reference to field isPersistent can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:38 - reference to field isSecure can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:39 - reference to field getValue can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:65 - call to parse can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:94 - call to formatCookies can't be resolved.
 [exec] Reflection warning, clj_http/cookies.clj:96 - reference to field getValue can't be resolved.
 [exec] Reflection warning, clj_http/core.clj:48 - call to java.lang.Integer ctor can't be resolved.
 [exec] Reflection warning, clj_http/core.clj:50 - call to java.lang.Integer ctor can't be resolved.

:as :json may hide status code errors with parse errors

There are a lot of apis that will return html instead of json when an error status is returned. clj-http tries to parse the body before checking status code which often then masks the status code error with a parse exception. For now, I simply removed :as :json and use the following as a work around:

    (-> (client/get ...)
        (update-in [:body] (comp walk/keywordize-keys json/parse-string))

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.