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.

Since 0.1.0

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.

Since 0.1.0

A convenient wrapper around withResponse which ignores the response body. This is useful, for example, when performing a HEAD request.

Since 0.3.2

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.

Since 0.1.0

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.

Since 0.1.0

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.

Since 0.4.1

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.

Since 0.4.1

A datatype holding information on redirected requests and the final response.

Since 0.4.1

Requests which resulted in a redirect, together with their responses. The response contains the first 1024 bytes of the body.

Since 0.4.1

The final request performed.

Since 0.4.1

The response from the final request.

Since 0.4.1

Keeps track of open connections for keep-alive.

If possible, you should share a single Manager between multiple threads and requests.

Since 0.1.0

Create a Manager. The Manager will be shut down automatically via garbage collection.

Creating a new Manager is a relatively expensive operation, you are advised to share a single Manager between requests instead.

The first argument to this function is often defaultManagerSettings, though add-on libraries may provide a recommended replacement.

Since 0.1.0

Close all connections in a Manager.

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.

Since 0.1.0

Create, use and close a Manager.

Since 0.2.1

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.

Since 0.1.0

Default value for ManagerSettings.

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.

Since 0.1.0

Number of connections to a single host to keep alive. Default: 10.

Since 0.1.0

Create an insecure connection.

Since 0.1.0 FIXME in the future, combine managerTlsConnection and managerTlsProxyConnection

Create a TLS connection. Default behavior: throw an exception that TLS is not supported.

Since 0.1.0

Default timeout (in microseconds) to be applied to requests which do not provide a timeout value.

Default is 30 seconds

Since 0.1.0

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.

Since 0.1.0

Action wrapped around all attempted Requests, usually used to wrap up exceptions in library-specific types.

Default: wrap all IOExceptions in the InternalIOException constructor.

Since 0.1.0

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.

Default: 512

Since 0.3.7

Perform the given modification to a Request before performing it.

Default: no modification

Since 0.4.4

Set the proxy override value, for both HTTP (insecure) and HTTPS (insecure) connections.

Since 0.4.7

Set the proxy override value, only for HTTP (insecure) connections.

Since 0.4.7

Set the proxy override value, only for HTTPS (secure) connections.

Since 0.4.7

How the HTTP proxy server settings should be discovered.

Since 0.4.7

Get the proxy settings from the Request itself.

Since 0.4.7

Never connect using a proxy, regardless of the proxy value in the Request.

Since 0.4.7

Use the given proxy settings, regardless of the proxy value in the Request.

Since 0.4.7

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.

Since 0.4.7

Same as proxyEnvironment, but instead of default environment variable names, allows you to set your own name.

Since 0.4.7

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.

Since 0.4.7

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.

Since 0.3.8

Convert a URL into a Request.

This defaults some of the values in Request, such as setting method to GET and requestHeaders to [].

Since this function uses MonadThrow, the return monad can be anything that is an instance of MonadThrow, such as IO or Maybe.

Since 0.1.0

Add a Basic Auth header (with the specified user name and password) to the given Request. Ignore error handling:

 applyBasicAuth "user" "pass" $ fromJust $ parseUrl url

Since 0.1.0

Add url-encoded parameters to the Request.

This sets a new requestBody, adds a content-type request header and changes the method to POST.

Since 0.1.0

Extract a URI from the request.

Since 0.1.0

Set the query string to the given key/value pairs.

Since 0.3.6

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 parseUrl.

The constructor for this data type is not exposed. Instead, you should use either the def method to retrieve a default instance, or parseUrl 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:

initReq <- parseUrl "http://www.example.com/path"
let req = initReq
            { method = "POST"
            }

For more information, please see http://www.yesodweb.com/book/settings-types.

Since 0.1.0

HTTP request method, eg GET, POST.

Since 0.1.0

Whether to use HTTPS (ie, SSL).

Since 0.1.0

Requested host name, used for both the IP address to connect to and the host request header.

Since 0.1.0

The port to connect to. Also used for generating the host request header.

Since 0.1.0

Everything from the host to the query string.

Since 0.1.0

Query string appended to the path.

Since 0.1.0

Custom HTTP request headers

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.

Since 0.1.0

Request body to be sent to the server.

Since 0.1.0

Optional HTTP proxy.

Since 0.1.0

Add a Proxy-Authorization header (with the specified username and password) to the given Request. Ignore error handling:

applyBasicProxyAuth "user" "pass" <$> parseUrl "http://example.org"

Since 0.3.4

Predicate to specify whether gzipped data should be decompressed on the fly (see alwaysDecompress and browserDecompress). Argument is the mime type. Default: browserDecompress.

Since 0.1.0

How many redirects to follow when getting a resource. 0 means follow no redirects. Default value: 10.

Since 0.1.0

Check the status code. Note that this will run after all redirects are performed. Default: return a StatusCodeException on non-2XX responses.

Since 0.1.0

Number of microseconds to wait for a response. If Nothing, will wait indefinitely. Default: use managerResponseTimeout (which by default is 30 seconds).

Since 0.1.0

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.

Since 0.1.0

HTTP version to send to server.

Default: HTTP 1.1

Since 0.4.3

When using one of the RequestBodyStream / RequestBodyStreamChunked constructors, you must ensure that the GivesPopper can be called multiple times. Usually this is not a problem.

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.

Since 0.1.0

A function which generates successive chunks of a request body, provider a single empty bytestring when no more data is available.

Since 0.1.0

A function which must be provided with a Popper.

Since 0.1.0

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.

Since 0.1.0

Send a file as the request body.

It is expected that the file size does not change between calling streamFile and making any requests using this request body.

Since 0.4.9

Send a file as the request body, while observing streaming progress via a PopObserver. Observations are made between reading and sending a chunk.

It is expected that the file size does not change between calling observedStreamFile and making any requests using this request body.

Since 0.4.9

Status of streaming a request body from a file.

Since 0.4.9

A simple representation of the HTTP response.

Since 0.1.0

Status code of the response.

Since 0.1.0

HTTP version used by the server.

Since 0.1.0

Response headers sent by the server.

Since 0.1.0

Response body sent by the server.

Since 0.1.0

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.

Since 0.1.0

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.

Since 0.4.0

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.

Since 0.1.0

Strictly consume all remaining chunks of data from the stream.

Since 0.1.0

Define a HTTP proxy, consisting of a hostname and port number.

This applies receiveSetCookie to a given Response

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.

Turn a SetCookie into a Cookie, if it is valid

Insert a cookie created by generateCookie into the cookie jar (or not if it shouldn't be allowed in)

This applies the computeCookieString to a given Request

This corresponds to the algorithm described in Section 5.4 "The Cookie Header"

This corresponds to the eviction algorithm described in Section 5.3 "Storage Model"

This corresponds to the subcomponent algorithm entitled "Path-Match" detailed in section 5.1.4

This corresponds to the subcomponent algorithm entitled "Domain Matching" detailed in section 5.1.3

This corresponds to the subcomponent algorithm entitled "Paths" detailed in section 5.1.4