The API below is rather low-level. The Network.HTTP.Simple module (from
the http-conduit package) provides a higher-level API with built-in
support for things like JSON request and response bodies. For most users,
this will be an easier place to start. You can read the tutorial at:
This is the main entry point for using http-client. Used by itself, this
module provides low-level access for streaming request and response bodies,
and only non-secure HTTP connections. Helper packages such as http-conduit
provide higher level streaming approaches, while other helper packages like
http-client-tls provide secure connections.
There are three core components to be understood here: requests, responses,
and managers. A Manager keeps track of open connections to various hosts,
and when requested, will provide either an existing open connection or
create a new connection on demand. A Manager also automatically reaps
connections which have been unused for a certain period of time. A Manager
allows for more efficient HTTP usage by allowing for keep-alive connections.
Secure HTTP connections can be allowed by modifying the settings used for
creating a manager. The simplest way to create a Manager is with:
While generally speaking it is a good idea to share a single Manager
throughout your application, there are cases where it makes more sense to
create and destroy Managers more frequently. As an example, if you have an
application which will make a large number of requests to different hosts,
and will never make more than one connection to a single host, then sharing
a Manager will result in idle connections being kept open longer than
necessary. In such a situation, it makes sense to use newManager before
each new request, to avoid running out of file descriptors. (Note that the
managerIdleConnectionCount setting mitigates the risk of leaking too many
file descriptors.)
The next core component is a Request, which represents a single HTTP
request to be sent to a specific server. Requests allow for many settings
to control exact how they function, but usually the simplest approach for
creating a Request is to use parseRequest.
Finally, a Response is the result of sending a single Request to a
server, over a connection which was acquired from a Manager. Note that you
must close the response when you're done with it to ensure that the
connection is recycled to the Manager to either be used by another
request, or to be reaped. Usage of withResponse will ensure that this
happens automatically.
Helper packages may provide replacements for various recommendations listed
above. For example, if using http-client-tls, instead of using
defaultManagerSettings, you would want to use tlsManagerSettings. Be
sure to read the relevant helper library documentation for more information.
A note on exceptions: for the most part, all actions that perform I/O should
be assumed to throw an HttpException in the event of some problem, and all
pure functions will be total. For example, withResponse, httpLbs, and
BodyReader can all throw exceptions. Functions like responseStatus and
applyBasicAuth are guaranteed to be total (or there's a bug in the
library).
One thing to be cautioned about: the type of parseRequest allows it to work in
different monads. If used in the IO monad, it will throw an exception in
the case of an invalid URI. In addition, if you leverage the IsString
instance of the Request value via OverloadedStrings, an invalid URI will
result in a partial value. Caveat emptor!
Perform a Request using a connection acquired from the given Manager,
and then provide the Response to the given function. This function is
fully exception safe, guaranteeing that the response will be closed when the
inner function exits. It is defined as:
withResponse req man f = bracket (responseOpen req man) responseClose f
It is recommended that you use this function in place of explicit calls to
responseOpen and responseClose.
You will need to use functions such as brRead to consume the response
body.
A convenience wrapper around withResponse which reads in the entire
response body and immediately closes the connection. Note that this function
performs fully strict I/O, and only uses a lazy ByteString in its response
for memory efficiency. If you are anticipating a large response body, you
are encouraged to use withResponse and brRead instead.
The most low-level function for initiating an HTTP request.
The first argument to this function gives a full specification
on the request: the host to connect to, whether to use SSL,
headers, etc. Please see Request for full details. The
second argument specifies which Manager should be used.
This function then returns a Response with a
BodyReader. The Response contains the status code
and headers that were sent back to us, and the
BodyReader contains the body of the request. Note
that this BodyReader allows you to have fully
interleaved IO actions during your HTTP download, making it
possible to download very large responses in constant memory.
An important note: the response body returned by this function represents a
live HTTP connection. As such, if you do not use the response body, an open
socket will be retained indefinitely. You must be certain to call
responseClose on this response to free up resources.
This function automatically performs any necessary redirects, as specified
by the redirectCount setting.
When implementing a (reverse) proxy using this function or relating
functions, it's wise to remove Transfer-Encoding:, Content-Length:,
Content-Encoding: and Accept-Encoding: from request and response
headers to be relayed.
Close any open resources associated with the given Response. In general,
this will either close an active Connection or return it to the Manager
to be reused.
A variant of withResponse which keeps a history of all redirects
performed in the interim, together with the first 1024 bytes of their
response bodies.
A variant of responseOpen which keeps a history of all redirects
performed in the interim, together with the first 1024 bytes of their
response bodies.
Note that this doesn't affect currently in-flight connections,
meaning you can safely use it without hurting any queries you may
have concurrently running.
Settings for a Manager. Please use the defaultManagerSettings function and then modify
individual settings. For more information, see http://www.yesodweb.com/book/settings-types.
Note that this value does not have support for SSL/TLS. If you need to
make any https connections, please use the http-client-tls package, which
provides a tlsManagerSettings value.
Exceptions for which we should retry our request if we were reusing an
already open connection. In the case of IOExceptions, for example, we
assume that the connection was closed on the server and therefore open a
new one.
Total number of idle connection to keep open at a given time.
This limit helps deal with the case where you are making a large number
of connections to different hosts. Without this limit, you could run out
of file descriptors. Additionally, it can be set to zero to prevent
reuse of any connections. Doing this is useful when the server your application
is talking to sits behind a load balancer.
Get the proxy settings from the default environment variable (http_proxy
for insecure, https_proxy for secure). If no variable is set, then fall
back to the given value. Nothing is equivalent to noProxy, Just is
equivalent to useProxy.
The default proxy settings for a manager. In particular: if the http_proxy (or https_proxy) environment variable is set, use it. Otherwise, use the values in the Request.
A value for the managerRawConnection setting, but also allows you to
modify the underlying Socket to set additional settings. For a motivating
use case, see: https://github.com/snoyberg/http-client/issues/71.
Same as rawConnectionModifySocket, but also takes in a chunk size.
Request
15 declarations
The way you parse string of characters to construct a Request will
determine whether exceptions will be thrown on non-2XX response status
codes. This is because the behavior is controlled by a setting in
Request itself (see checkResponse) and different parsing functions
set it to different IO actions.
This can fail if the given URI is not absolute, or if the
URI scheme is not "http" or "https". In these cases the function
will throw an error via MonadThrow.
This function defaults some of the values in Request, such as setting method to
GET and requestHeaders to [].
A Request created by this function won't cause exceptions on non-2XX
response status codes.
Add a Basic Auth header (with the specified user name and password) to the
given Request. Ignore error handling:
applyBasicAuth "user" "pass" $ parseRequest_ url
NOTE: The function applyDigestAuth is provided by the http-client-tls
package instead of this package due to extra dependencies. Please use that
package if you need to use digest authentication.
All information on how to connect to a host and what should be sent in the
HTTP request.
If you simply wish to download from a URL, see parseRequest.
The constructor for this data type is not exposed. Instead, you should use
either the defaultRequest value, or parseRequest to
construct from a URL, and then use the records below to make modifications.
This approach allows http-client to add configuration options without
breaking backwards compatibility.
For example, to construct a POST request, you could do something like:
The Content-Length and Transfer-Encoding headers are set automatically
by this module, and shall not be added to requestHeaders.
If not provided by the user, Host will automatically be set based on
the host and port fields.
Moreover, the Accept-Encoding header is set implicitly to gzip for
convenience by default. This behaviour can be overridden if needed, by
setting the header explicitly to a different value. In order to omit the
Accept-Header altogether, set it to the empty string "". If you need an
empty Accept-Header (i.e. requesting the identity encoding), set it to a
non-empty white-space string, e.g. " ". See RFC 2616 section 14.3 for
details about the semantics of the Accept-Header field. If you request a
content-encoding not supported by this module, you will have to decode
it yourself (see also the decompress field).
Note: Multiple header fields with the same field-name will result in
multiple header fields being sent and therefore it's the responsibility
of the client code to ensure that the rules from RFC 2616 section 4.2
are honoured.
Predicate to specify whether gzipped data should be
decompressed on the fly (see alwaysDecompress and
browserDecompress). Argument is the mime type.
Default: browserDecompress.
Decide whether a header must be stripped from the request
when following a redirect, if host differs from previous request
in redirect chain. Default: false (always strip regardless of host change)
Check the response immediately after receiving the status and headers.
This can be useful for throwing exceptions on non-success status codes.
In previous versions of http-client, this went under the name
checkStatus, but was renamed to avoid confusion about the new default
behavior (doing nothing).
Number of microseconds to wait for a response (see ResponseTimeout
for more information). Default: use managerResponseTimeout (which by
default is 30 seconds).
A user-defined cookie jar.
If Nothing, no cookie handling will take place, "Cookie" headers
in requestHeaders will be sent raw, and responseCookieJar will be
empty.
The RequestBodyStreamChunked will send a chunked request body. Note that
not all servers support this. Only use RequestBodyStreamChunked if you
know the server you're sending to supports chunked request bodies.
A function which will provide a Popper to a NeedsPopper. This
seemingly convoluted structure allows for creation of request bodies which
allocate scarce resources in an exception safe manner.
Cookies set on the client after interacting with the server. If
cookies have been disabled by setting cookieJar to Nothing, then
this will always be empty.
An IO action that represents an incoming response body coming from the
server. Data provided by this action has already been gunzipped and
de-chunked, and respects any content-length headers present.
The action gets a single chunk of data from the response body, or an empty
bytestring if no more data is available.
Get a single chunk of data from the response body, or an empty
bytestring if no more data is available.
Note that in order to consume the entire request body, you will need to
repeatedly call this function until you receive an empty ByteString as a
result.
The server responded with too many redirects for a
request.
Contains the list of encountered responses containing
redirects in reverse chronological order; including last
redirect, which triggered the exception and was not
followed.
An exception was raised by an underlying library when
performing the request. Most often, this is caused by a
failing socket action or a TLS exception.
No response data was received from the server at all.
This exception may deserve special handling within the
library, since it may indicate that a pipelining has been
used, and a connection thought to be open was in fact
closed.
Exception thrown when using a Manager which does not
have support for secure connections. Typically, you will
want to use tlsManagerSettings from http-client-tls
to overcome this.
Since there was some confusion in the history of this library about how the Eq instance
should work, it was removed for clarity, and replaced by equal and equiv. equal
gives you equality of all fields of the Cookie record.
This corresponds to the algorithm described in Section 5.3 "Storage Model"
This function consists of calling generateCookie followed by insertCheckedCookie.
Use this function if you plan to do both in a row.
generateCookie and insertCheckedCookie are only provided for more fine-grained control.