This module provides the API to a HTTP/1.1 compatible client according to RFC 2616, caching is currently not supported.
When starting the Inets application a manager process for the default profile will be started. The functions in this API that do not explicitly use a profile will access the default profile. A profile keeps track of proxy options, cookies and other options that can be applied to more than one request.
If the scheme https is used the ssl application needs to be started.
Also note that pipelining will only be used if the pipeline timeout is set, otherwise persistent connections without pipelining will be used e.i. the client always waits for the previous response before sending the next request.
There are some usage examples in the
Type definitions that are used more than once in this module:
Type definitions that are related to HTTP:
For more information about HTTP see rfc 2616
body_processing_result(),
accumulator()} |
{chunkify,
fun(accumulator()) -> body_processing_result(),
accumulator()}
body_processing_result() = eof | {ok, iolist(), accumulator()}
accumulator() = term()
filename() = string()
]]>
See
A HTTP client can be configured to start when starting the inets
application or started dynamically in runtime by calling the
inets application API
The client can be stopped using
Equivalent to
Sends a HTTP-request. The function can be both synchronous
and asynchronous. In the later case the function will return
Http option (
Timeout time for the request.
The clock starts ticking as soon as the request has been sent.
Time is in milliseconds.
Defaults to
Connection timeout time, used during the initial request, when the client is connecting to the server.
Time is in milliseconds.
Defaults to the value of the
This is the default ssl config option, currently defaults to
Defaults to
If using the OpenSSL based (old) implementation of SSL, these SSL-specific options are used.
Defaults to
If using the Erlang based (new) implementation of SSL, these SSL-specific options are used.
Defaults to
Should the client automatically retrieve the information from the new URI and return that as the result instead of a 30X-result code.
Note that for some 30X-result codes automatic redirect is not allowed. In these cases the 30X-result will always be returned.
Defaults to
A proxy-authorization header using the provided user name and password will be added to the request.
Can be used to make the client act as an
Defaults to the string
If set to
Defaults to
Will apply Percent-encoding, also known as URL encoding on the URL.
Defaults to
Option (
Shall the request be synchronous or asynchronous.
Defaults to
Streams the body of a 200 or 206 response to the calling
process or to a file. When streaming to the calling process
using the option
Note that it is possible that chunked encoding will add
headers so that there are more headers in the
Defaults to
Defines if the body shall be delivered as a string or as a binary. This option is only valid for the synchronous request.
Defaults to
Should a "full result" be returned to the caller (that is, the body, the headers and the entire status-line) or not (the body and the status code).
Defaults to
Shall the headers provided by the user be made lower case or be regarded as case sensitive.
Note that the http standard requires them to be case insenstive. This feature should only be used if there is no other way to communicate with the server or for testing purpose. Also note that when this option is used no headers will be automatically added, all necessary headers have to be provided by the user.
Defaults to
Socket options to be used for this and subsequent request(s).
Overrides any value set by the
Note that the validity of the options are not checked in any way.
Note that this may change the socket behaviour
(see
By default the socket options set by the
Defines how the client will deliver the result of an
asynchroneous request (
Message(s) will be sent to this process in the format:
{http, ReplyInfo}
Information will be delivered to the receiver via calls to the provided fun:
Receiver(ReplyInfo)
Information will be delivered to the receiver via calls to the callback function:
apply(Module, Function, [ReplyInfo | Args])
In all of the above cases,
{RequestId, saved_to_file} {RequestId, {error, Reason}} {RequestId, Result} {RequestId, stream_start, Headers} {RequestId, stream_start, Headers, HandlerPid} {RequestId, stream, BinBodyPart} {RequestId, stream_end, Headers}
Defaults to the
Cancels an asynchronous HTTP-request.
Sets options to be used for subsequent requests.
If possible the client will keep its connections
alive and use persistent connections
with or without pipeline depending on configuration
and current circumstances. The HTTP/1.1 specification does not
provide a guideline for how many requests would be
ideal to be sent on a persistent connection,
this very much depends on the
application. Note that a very long queue of requests may cause a
user perceived delay as earlier requests may take a long time
to complete. The HTTP/1.1 specification does suggest a
limit of 2 persistent connections per server, which is the
default value of the
Triggers the next message to be streamed, e.i. same behavior as active once for sockets.
Saves the cookies defined in SetCookieHeaders
in the client profile's cookie database. You need to
call this function if you have set the option
Returns the cookie header that would be sent
when making a request to
Resets (clears) the cookie database for the specified
This function produces a list of the entire cookie database. It is intended for debugging/testing purposes. If no profile is specified the default profile will be used.
RFC 2616,