Documentation

Network.HTTP.Client.Request stores the request body in a sum type which has a case containing IO along with some other unwieldy cases. This makes it difficult to log our requests before and after transformation.

In our codebase we only ever use the Lazy ByteString case. So by lifting the request body out of Network.HTTP.Client.Request, we make it much easier to log our Requests.

When executing the request we simply insert the value at rdBody into the Request.

When working with Transformable Requests you should always import this module qualified and use the `mkRequest*` functions for constructing requests. Modification of Request should be done using the provided lens API.

NOTE: This module is meant to be imported qualified, e.g.

 import qualified Network.HTTP.Client.Transformable as HTTP

...or

 import qualified Network.HTTP.Client.Transformable as Transformable

Use performRequest to execute the request.

Convert a URL into a Request value.

NOTE: This function will throw an error in MonadThrow if the URL is invalid.

mkRequestThrow with the MonadThrow instance specialized to Either.

NOTE: While this function makes use of impureThrow, it should be impossible to trigger in practice.

mkRequestThrow calls parseRequest, which only ever throws HttpException errors (which should be "caught" by the fromException cast).

Creates a Request, converting it from a Request. This only supports requests that use a Strict/Lazy ByteString as a request body and will fail with all other body types.

NOTE: You should avoid creating Requests and use the mk functions to create Requests. This is for if a framework hands you a precreated Request and you don't have a choice.

Url is 'materialized view' into Request consisting of concatenation of host, port, queryParams, and path in the underlying request object, as well as a literal url field that stores the textual representation that was supplied from metadata.

The reason why we store the textual URL in addition to the parsed URL in the request is that the parsed URL loses syntactic information such as "does http://foo.com end in a slash?" which is important when a template user has expectations about the $url variable matching the string that was configured in the action.

We use the literal field to view the value but we must carefully set the subcomponents by hand during set operations. Be careful modifying this lens and verify against the unit tests..

NOTE: for now, please always wrap this in tracedHttpRequest to make sure a trace is logged.