-Whether to enable the extended CONNECT method to allow
-protocols like Websocket to be used over an HTTP/2 stream.
-This option is experimental and disabled by default.
+ Whether to enable the extended CONNECT method to allow
+ protocols like Websocket to be used over an HTTP/2 stream.
+ This option is experimental and disabled by default.
-Time in ms with nothing received at all before Cowboy closes the connection.
+ Time in ms with nothing received at all before Cowboy closes the connection.
-Initial window size for the connection. This is the total amount
-of data (from request bodies for example) that may be buffered
-by the connection across all streams before the user code
-explicitly requests it.
+ Initial window size for the connection. This is the total amount
+ of data (from request bodies for example) that may be buffered
+ by the connection across all streams before the user code
+ explicitly requests it.
-
Note that this value cannot be lower than the default.
+
+
+
Note that this value cannot be lower than the default.
+
initial_stream_window_size (65535)
-Initial window size for new streams. This is the total amount
-of data (from request bodies for example) that may be buffered
-by a single stream before the user code explicitly requests it.
+ Initial window size for new streams. This is the total amount
+ of data (from request bodies for example) that may be buffered
+ by a single stream before the user code explicitly requests it.
-Maximum number of concurrent streams allowed on the connection.
+ Maximum number of concurrent streams allowed on the connection.
@@ -180,9 +181,9 @@ max_decode_table_size (4096)
-Maximum header table size used by the decoder. This is the value advertised
-to the client. The client can then choose a header table size equal or lower
-to the advertised value.
+ Maximum header table size used by the decoder. This is the value advertised
+ to the client. The client can then choose a header table size equal or lower
+ to the advertised value.
@@ -190,9 +191,9 @@ max_encode_table_size (4096)
-Maximum header table size used by the encoder. The server will compare this
-value to what the client advertises and choose the smallest one as the
-encoder’s header table size.
+ Maximum header table size used by the encoder. The server will compare this
+ value to what the client advertises and choose the smallest one as the
+ encoder’s header table size.
-Maximum size of the frames received by the server. This value is
-advertised to the remote endpoint which can then decide to use
-any value lower or equal for its frame sizes.
+ Maximum size of the frames received by the server. This value is
+ advertised to the remote endpoint which can then decide to use
+ any value lower or equal for its frame sizes.
-Maximum size of the frames sent by the server. This option allows
-setting an upper limit to the frame sizes instead of blindly
-following the client’s advertised maximum.
+ Maximum size of the frames sent by the server. This option allows
+ setting an upper limit to the frame sizes instead of blindly
+ following the client’s advertised maximum.
-
Note that actual frame sizes may be lower than the limit when
-there is not enough space left in the flow control window.
+
+
+
Note that actual frame sizes may be lower than the limit when
+there is not enough space left in the flow control window.
+
middlewares ([cowboy_router, cowboy_handler])
-Middlewares to run for every request.
+ Middlewares to run for every request.
@@ -230,7 +234,7 @@ preface_timeout (5000)
-Time in ms Cowboy is willing to wait for the connection preface.
+ Time in ms Cowboy is willing to wait for the connection preface.
@@ -238,7 +242,7 @@ settings_timeout (5000)
-Time in ms Cowboy is willing to wait for a SETTINGS ack.
+ Time in ms Cowboy is willing to wait for a SETTINGS ack.
@@ -246,7 +250,7 @@ shutdown_timeout (5000)
-Time in ms Cowboy will wait for child processes to shut down before killing them.
+ Time in ms Cowboy will wait for child processes to shut down before killing them.
If you have a large set of environment variables, you may find it
+easier to use a separate file. Do this by including the following
+in your Makefile:
The src/$(PROJECT).app.src file is a legacy method of
building Erlang applications. It was introduced by the original
diff --git a/docs/en/erlang.mk/1/guide/asciidoc/index.html b/docs/en/erlang.mk/1/guide/asciidoc/index.html
index 472047e8..bb13a400 100644
--- a/docs/en/erlang.mk/1/guide/asciidoc/index.html
+++ b/docs/en/erlang.mk/1/guide/asciidoc/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: AsciiDoc documentation
diff --git a/docs/en/erlang.mk/1/guide/ci/index.html b/docs/en/erlang.mk/1/guide/ci/index.html
index 1edf4b3f..cacdb813 100644
--- a/docs/en/erlang.mk/1/guide/ci/index.html
+++ b/docs/en/erlang.mk/1/guide/ci/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Continuous integration
diff --git a/docs/en/erlang.mk/1/guide/common_test/index.html b/docs/en/erlang.mk/1/guide/common_test/index.html
index 796acdef..f6430831 100644
--- a/docs/en/erlang.mk/1/guide/common_test/index.html
+++ b/docs/en/erlang.mk/1/guide/common_test/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Common Test
@@ -203,8 +201,8 @@ but covered in its own chapter.
-
- Code coverage
+
+ Triq
diff --git a/docs/en/erlang.mk/1/guide/compat/index.html b/docs/en/erlang.mk/1/guide/compat/index.html
index 9f7facac..56ec41dc 100644
--- a/docs/en/erlang.mk/1/guide/compat/index.html
+++ b/docs/en/erlang.mk/1/guide/compat/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Compatibility with other build tools
diff --git a/docs/en/erlang.mk/1/guide/contributing/index.html b/docs/en/erlang.mk/1/guide/contributing/index.html
index 8db4fccd..97a00e86 100644
--- a/docs/en/erlang.mk/1/guide/contributing/index.html
+++ b/docs/en/erlang.mk/1/guide/contributing/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Contributing
diff --git a/docs/en/erlang.mk/1/guide/coverage/index.html b/docs/en/erlang.mk/1/guide/coverage/index.html
index 34654df8..aa986318 100644
--- a/docs/en/erlang.mk/1/guide/coverage/index.html
+++ b/docs/en/erlang.mk/1/guide/coverage/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Code coverage
@@ -77,8 +75,8 @@
The shell can be stopped as usual with a double Ctrl+C or the
command q()..
+
Note that the shell target does not build the application. To do it,
+use either the app target or, if you want to include also test
+modules, the test-build target.
diff --git a/docs/en/erlang.mk/1/guide/sphinx/index.html b/docs/en/erlang.mk/1/guide/sphinx/index.html
index bcf2ac5a..379dc8a6 100644
--- a/docs/en/erlang.mk/1/guide/sphinx/index.html
+++ b/docs/en/erlang.mk/1/guide/sphinx/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Sphinx documentation
diff --git a/docs/en/erlang.mk/1/guide/triq.asciidoc b/docs/en/erlang.mk/1/guide/triq.asciidoc
new file mode 100644
index 00000000..db698600
--- /dev/null
+++ b/docs/en/erlang.mk/1/guide/triq.asciidoc
@@ -0,0 +1,31 @@
+[[triq]]
+== Triq
+
+https://triq.gitlab.io/[Triq] is a QuickCheck-like library for
+property-based testing. Erlang.mk automates discovery and checking of
+Triq properties.
+
+To run all tests (including Triq):
+
+[source,bash]
+$ make tests
+
+To run all tests and static checks (including Triq):
+
+[source,bash]
+$ make check
+
+You can also run Triq separately:
+
+[source,bash]
+$ make triq
+
+To check properties from a single module:
+
+[source,bash]
+$ make triq t=foo_tests
+
+To check a single property:
+
+[source,bash]
+$ make triq t=foo_tests:bar
diff --git a/docs/en/erlang.mk/1/guide/triq/index.html b/docs/en/erlang.mk/1/guide/triq/index.html
new file mode 100644
index 00000000..5b478a0b
--- /dev/null
+++ b/docs/en/erlang.mk/1/guide/triq/index.html
@@ -0,0 +1,188 @@
+
+
+
+
+
+
+
+
+
+ Nine Nines: Triq
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/en/erlang.mk/1/guide/updating/index.html b/docs/en/erlang.mk/1/guide/updating/index.html
index 510f0a1c..44f5adb4 100644
--- a/docs/en/erlang.mk/1/guide/updating/index.html
+++ b/docs/en/erlang.mk/1/guide/updating/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Updating Erlang.mk
diff --git a/docs/en/erlang.mk/1/guide/why/index.html b/docs/en/erlang.mk/1/guide/why/index.html
index 1318ed5f..a18ba0d2 100644
--- a/docs/en/erlang.mk/1/guide/why/index.html
+++ b/docs/en/erlang.mk/1/guide/why/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Why Erlang.mk
diff --git a/docs/en/erlang.mk/1/guide/xref/index.html b/docs/en/erlang.mk/1/guide/xref/index.html
index 80960265..6de10fea 100644
--- a/docs/en/erlang.mk/1/guide/xref/index.html
+++ b/docs/en/erlang.mk/1/guide/xref/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Xref
diff --git a/docs/en/gun/1.0/guide/connect.asciidoc b/docs/en/gun/1.0/guide/connect.asciidoc
index e0b09d6c..dd4297d1 100644
--- a/docs/en/gun/1.0/guide/connect.asciidoc
+++ b/docs/en/gun/1.0/guide/connect.asciidoc
@@ -1,3 +1,4 @@
+[[connect]]
== Connection
This chapter describes how to open, monitor and close
@@ -26,31 +27,33 @@ to reconnect automatically.
=== Opening a new connection
-The `gun:open/{2,3}` function must be used to open a connection.
+The `gun:open/2,3` function must be used to open a connection.
.Opening a connection to example.org on port 443
-
[source,erlang]
+----
{ok, ConnPid} = gun:open("example.org", 443).
+----
If the port given is 443, Gun will attempt to connect using
-SSL. The protocol will be selected automatically using the
+TLS. The protocol will be selected automatically using the
ALPN extension for TLS. By default Gun supports HTTP/2
-and HTTP/1.1 when connecting using SSL.
+and HTTP/1.1 when connecting using TLS.
-For any other port, Gun will attempt to connect using TCP
-and will use the HTTP/1.1 protocol.
+For any other port, Gun will attempt to connect using
+plain TCP and will use the HTTP/1.1 protocol.
-The transport and protocol used can be overriden using
+The transport and protocol used can be overriden via
options. The manual documents all available options.
Options can be provided as a third argument, and take the
form of a map.
-.Opening an SSL connection to example.org on port 8443
-
+.Opening a TLS connection to example.org on port 8443
[source,erlang]
-{ok, ConnPid} = gun:open("example.org", 8443, #{transport=>ssl}).
+----
+{ok, ConnPid} = gun:open("example.org", 8443, #{transport => tls}).
+----
=== Waiting for the connection to be established
@@ -58,22 +61,23 @@ When Gun successfully connects to the server, it sends a
`gun_up` message with the protocol that has been selected
for the connection.
-Gun provides the functions `gun:await_up/{1,2,3}` that wait
+Gun provides the functions `gun:await_up/1,2,3` that wait
for the `gun_up` message. They can optionally take a monitor
reference and/or timeout value. If no monitor is provided,
one will be created for the duration of the function call.
.Synchronous opening of a connection
-
[source,erlang]
+----
{ok, ConnPid} = gun:open("example.org", 443),
{ok, Protocol} = gun:await_up(ConnPid).
+----
=== Handling connection loss
When the connection is lost, Gun will send a `gun_down`
message indicating the current protocol, the reason the
-connection was lost and two list of stream references.
+connection was lost and two lists of stream references.
The first list indicates open streams that _may_ have been
processed by the server. The second list indicates open
@@ -81,41 +85,41 @@ streams that the server did not process.
=== Monitoring the connection process
-@todo Gun should detect the owner process being killed
-
Because software errors are unavoidable, it is important to
detect when the Gun process crashes. It is also important
to detect when it exits normally. Erlang provides two ways
to do that: links and monitors.
Gun leaves you the choice as to which one will be used.
-However, if you use the `gun:await/{2,3}` or `gun:await_body/{2,3}`
+However, if you use the `gun:await/2,3` or `gun:await_body/2,3`
functions, a monitor may be used for you to avoid getting
stuck waiting for a message that will never come.
If you choose to monitor yourself you can do it on a permanent
basis rather than on every message you will receive, saving
-resources. Indeed, the `gun:await/{3,4}` and `gun:await_body/{3,4}`
+resources. Indeed, the `gun:await/3,4` and `gun:await_body/3,4`
functions both accept a monitor argument if you have one already.
.Monitoring the connection process
-
[source,erlang]
+----
{ok, ConnPid} = gun:open("example.org", 443).
MRef = monitor(process, ConnPid).
+----
This monitor reference can be kept and used until the connection
process exits.
.Handling `DOWN` messages
-
[source,erlang]
+----
receive
- %% Receive Gun messages here...
- {'DOWN', Mref, process, ConnPid, Reason} ->
- error_logger:error_msg("Oops!"),
- exit(Reason);
+ %% Receive Gun messages here...
+ {'DOWN', Mref, process, ConnPid, Reason} ->
+ error_logger:error_msg("Oops!"),
+ exit(Reason)
end.
+----
What to do when you receive a `DOWN` message is entirely up to you.
@@ -125,30 +129,32 @@ The connection can be stopped abruptly at any time by calling
the `gun:close/1` function.
.Immediate closing of the connection
-
[source,erlang]
+----
gun:close(ConnPid).
+----
The process is stopped immediately without having a chance to
perform the protocol's closing handshake, if any.
-=== Closing the connection gracefully
-
-The connection can also be stopped gracefully by calling the
-`gun:shutdown/1` function.
-
-.Graceful shutdown of the connection
-
-[source,erlang]
-gun:shutdown(ConnPid).
-
-Gun will refuse any new requests or messages after you call
-this function. It will however continue to send you messages
-for existing streams until they are all completed.
-
-For example if you performed a GET request just before calling
-`gun:shutdown/1`, you will still receive the response before
-Gun closes the connection.
-
-If you set a monitor beforehand, you will receive a message
-when the connection has been closed.
+//=== Closing the connection gracefully
+//
+//The connection can also be stopped gracefully by calling the
+//`gun:shutdown/1` function.
+//
+//.Graceful shutdown of the connection
+//[source,erlang]
+//----
+//gun:shutdown(ConnPid).
+//----
+//
+//Gun will refuse any new requests or messages after you call
+//this function. It will however continue to send you messages
+//for existing streams until they are all completed.
+//
+//For example if you performed a GET request just before calling
+//`gun:shutdown/1`, you will still receive the response before
+//Gun closes the connection.
+//
+//If you set a monitor beforehand, you will receive a message
+//when the connection has been closed.
diff --git a/docs/en/gun/1.0/guide/connect/index.html b/docs/en/gun/1.0/guide/connect/index.html
index 1e35e16b..ac1e6eb3 100644
--- a/docs/en/gun/1.0/guide/connect/index.html
+++ b/docs/en/gun/1.0/guide/connect/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Connection
@@ -89,7 +87,7 @@ to reconnect automatically.
Opening a new connection
-
The gun:open/{2,3} function must be used to open a connection.
+
The gun:open/2,3 function must be used to open a connection.
Opening a connection to example.org on port 443
{ok, ConnPid} =gun:open("example.org", 443).
If the port given is 443, Gun will attempt to connect using
-SSL. The protocol will be selected automatically using the
+TLS. The protocol will be selected automatically using the
ALPN extension for TLS. By default Gun supports HTTP/2
-and HTTP/1.1 when connecting using SSL.
-
For any other port, Gun will attempt to connect using TCP
-and will use the HTTP/1.1 protocol.
-
The transport and protocol used can be overriden using
+and HTTP/1.1 when connecting using TLS.
+
For any other port, Gun will attempt to connect using
+plain TCP and will use the HTTP/1.1 protocol.
+
The transport and protocol used can be overriden via
options. The manual documents all available options.
Options can be provided as a third argument, and take the
form of a map.
-
Opening an SSL connection to example.org on port 8443
+
Opening a TLS connection to example.org on port 8443
When Gun successfully connects to the server, it sends a
gun_up message with the protocol that has been selected
for the connection.
-
Gun provides the functions gun:await_up/{1,2,3} that wait
+
Gun provides the functions gun:await_up/1,2,3 that wait
for the gun_up message. They can optionally take a monitor
reference and/or timeout value. If no monitor is provided,
one will be created for the duration of the function call.
When the connection is lost, Gun will send a gun_down
message indicating the current protocol, the reason the
-connection was lost and two list of stream references.
+connection was lost and two lists of stream references.
The first list indicates open streams that may have been
processed by the server. The second list indicates open
streams that the server did not process.
@@ -150,18 +148,17 @@ streams that the server did not process.
Monitoring the connection process
-
@todo Gun should detect the owner process being killed
Because software errors are unavoidable, it is important to
detect when the Gun process crashes. It is also important
to detect when it exits normally. Erlang provides two ways
to do that: links and monitors.
Gun leaves you the choice as to which one will be used.
-However, if you use the gun:await/{2,3} or gun:await_body/{2,3}
+However, if you use the gun:await/2,3 or gun:await_body/2,3
functions, a monitor may be used for you to avoid getting
stuck waiting for a message that will never come.
If you choose to monitor yourself you can do it on a permanent
basis rather than on every message you will receive, saving
-resources. Indeed, the gun:await/{3,4} and gun:await_body/{3,4}
+resources. Indeed, the gun:await/3,4 and gun:await_body/3,4
functions both accept a monitor argument if you have one already.
Monitoring the connection process
@@ -180,10 +177,10 @@ by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
What to do when you receive a DOWN message is entirely up to you.
@@ -204,28 +201,6 @@ http://www.gnu.org/software/src-highlite -->
perform the protocol’s closing handshake, if any.
-
-
Closing the connection gracefully
-
-
The connection can also be stopped gracefully by calling the
-gun:shutdown/1 function.
-
-
Graceful shutdown of the connection
-
-
gun:shutdown(ConnPid).
-
Gun will refuse any new requests or messages after you call
-this function. It will however continue to send you messages
-for existing streams until they are all completed.
-
For example if you performed a GET request just before calling
-gun:shutdown/1, you will still receive the response before
-Gun closes the connection.
-
If you set a monitor beforehand, you will receive a message
-when the connection has been closed.
-
-
diff --git a/docs/en/gun/1.0/guide/gun.sty b/docs/en/gun/1.0/guide/gun.sty
new file mode 100644
index 00000000..d5e0d3be
--- /dev/null
+++ b/docs/en/gun/1.0/guide/gun.sty
@@ -0,0 +1,8 @@
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{asciidoc-dblatex}[2012/10/24 AsciiDoc DocBook Style]
+
+%% Just use the original package and pass the options.
+\RequirePackageWithOptions{docbook}
+
+%% Define an alias for make snippets to be compatible with source-highlighter.
+\lstalias{makefile}{make}
diff --git a/docs/en/gun/1.0/guide/http.asciidoc b/docs/en/gun/1.0/guide/http.asciidoc
index ff4aa0aa..652030a3 100644
--- a/docs/en/gun/1.0/guide/http.asciidoc
+++ b/docs/en/gun/1.0/guide/http.asciidoc
@@ -1,3 +1,4 @@
+[[http]]
== HTTP
This chapter describes how to use the Gun client for
@@ -7,7 +8,7 @@ communicating with an HTTP/1.1 or HTTP/2 server.
Every time a request is initiated, Gun creates a _stream_.
A _stream reference_ uniquely identifies a set of request and
-response(s) and must be used to perform additional operations
+response and must be used to perform additional operations
with a stream or to identify its messages.
Stream references use the Erlang _reference_ data type and
@@ -24,7 +25,9 @@ not be used.
.Cancelling a stream
[source,erlang]
+----
gun:cancel(ConnPid, StreamRef).
+----
=== Sending requests
@@ -45,39 +48,43 @@ handling of responses will be explained further on.
==== GET and HEAD
-Use `gun:get/{2,3,4}` to request a resource.
+Use `gun:get/2,3,4` to request a resource.
.GET "/organizations/ninenines"
-
[source,erlang]
+----
StreamRef = gun:get(ConnPid, "/organizations/ninenines").
+----
.GET "/organizations/ninenines" with custom headers
-
[source,erlang]
+----
StreamRef = gun:get(ConnPid, "/organizations/ninenines", [
- {<<"accept">>, "application/json"},
- {<<"user-agent">>, "revolver/1.0"}
+ {<<"accept">>, "application/json"},
+ {<<"user-agent">>, "revolver/1.0"}
]).
+----
Note that the list of headers has the field name as a binary.
The field value is iodata, which is either a binary or an
iolist.
-Use `gun:head/{2,3,4}` if you don't need the response body.
+Use `gun:head/2,3,4` if you don't need the response body.
.HEAD "/organizations/ninenines"
-
[source,erlang]
+----
StreamRef = gun:head(ConnPid, "/organizations/ninenines").
+----
.HEAD "/organizations/ninenines" with custom headers
-
[source,erlang]
+----
StreamRef = gun:head(ConnPid, "/organizations/ninenines", [
- {<<"accept">>, "application/json"},
- {<<"user-agent">>, "revolver/1.0"}
+ {<<"accept">>, "application/json"},
+ {<<"user-agent">>, "revolver/1.0"}
]).
+----
It is not possible to send a request body with a GET or HEAD
request.
@@ -87,7 +94,7 @@ request.
HTTP defines three methods to create or update a resource.
POST is generally used when the resource identifier (URI) isn't known
-in advance when creating the resource. POST can also be used to
+in advance when creating a resource. POST can also be used to
replace an existing resource, although PUT is more appropriate
in that situation.
@@ -101,7 +108,7 @@ desirable. The request body of a PATCH method may be a partial
representation or a list of instructions on how to update the
resource.
-The `gun:post/{4,5}`, `gun:put/{4,5}` and `gun:patch/{4,5}` functions
+The `gun:post/4,5`, `gun:put/4,5` and `gun:patch/4,5` functions
take a body as their fourth argument. These functions do
not require any body-specific header to be set, although
it is always recommended to set the content-type header.
@@ -112,12 +119,13 @@ can be replaced by `gun:put` or `gun:patch` for performing
a PUT or PATCH request, respectively.
.POST "/organizations/ninenines"
-
[source,erlang]
+----
Body = "{\"msg\": \"Hello world!\"}",
StreamRef = gun:post(ConnPid, "/organizations/ninenines", [
- {<<"content-type">>, "application/json"}
+ {<<"content-type">>, "application/json"}
], Body).
+----
The `gun:post/3`, `gun:put/3` and `gun:patch/3` functions
do not take a body in their arguments. If a body is to be
@@ -133,14 +141,15 @@ is not set, HTTP/1.1 will use the chunked transfer-encoding,
and HTTP/2 will continue normally as it is chunked by design.
.POST "/organizations/ninenines" with delayed body
-
[source,erlang]
+----
Body = "{\"msg\": \"Hello world!\"}",
StreamRef = gun:post(ConnPid, "/organizations/ninenines", [
- {<<"content-length">>, integer_to_binary(length(Body))},
- {<<"content-type">>, "application/json"}
+ {<<"content-length">>, integer_to_binary(length(Body))},
+ {<<"content-type">>, "application/json"}
]),
gun:data(ConnPid, StreamRef, fin, Body).
+----
The atom `fin` indicates this is the last chunk of data to
be sent. You can call the `gun:data/4` function as many
@@ -148,79 +157,82 @@ times as needed until you have sent the entire body. The
last call must use `fin` and all the previous calls must
use `nofin`. The last chunk may be empty.
-@todo what to do about empty chunk, ignore?
-
.Streaming the request body
-
[source,erlang]
----
sendfile(ConnPid, StreamRef, Filepath) ->
- {ok, IoDevice} = file:open(Filepath, [read, binary, raw]),
- do_sendfile(ConnPid, StreamRef, IoDevice).
+ {ok, IoDevice} = file:open(Filepath, [read, binary, raw]),
+ do_sendfile(ConnPid, StreamRef, IoDevice).
do_sendfile(ConnPid, StreamRef, IoDevice) ->
- case file:read(IoDevice, 8000) of
- eof ->
- gun:data(ConnPid, StreamRef, fin, <<>>),
- file:close(IoDevice);
- {ok, Bin} ->
- gun:data(ConnPid, StreamRef, nofin, Bin),
- do_sendfile(ConnPid, StreamRef, IoDevice)
- end.
+ case file:read(IoDevice, 8000) of
+ eof ->
+ gun:data(ConnPid, StreamRef, fin, <<>>),
+ file:close(IoDevice);
+ {ok, Bin} ->
+ gun:data(ConnPid, StreamRef, nofin, Bin),
+ do_sendfile(ConnPid, StreamRef, IoDevice)
+ end.
----
==== DELETE
-Use `gun:delete/{2,3,4}` to delete a resource.
+Use `gun:delete/2,3,4` to delete a resource.
.DELETE "/organizations/ninenines"
-
[source,erlang]
+----
StreamRef = gun:delete(ConnPid, "/organizations/ninenines").
+----
.DELETE "/organizations/ninenines" with custom headers
-
[source,erlang]
+----
StreamRef = gun:delete(ConnPid, "/organizations/ninenines", [
- {<<"user-agent">>, "revolver/1.0"}
+ {<<"user-agent">>, "revolver/1.0"}
]).
+----
==== OPTIONS
-Use `gun:options/{2,3}` to request information about a resource.
+Use `gun:options/2,3` to request information about a resource.
.OPTIONS "/organizations/ninenines"
-
[source,erlang]
+----
StreamRef = gun:options(ConnPid, "/organizations/ninenines").
+----
.OPTIONS "/organizations/ninenines" with custom headers
-
[source,erlang]
+----
StreamRef = gun:options(ConnPid, "/organizations/ninenines", [
- {<<"user-agent">>, "revolver/1.0"}
+ {<<"user-agent">>, "revolver/1.0"}
]).
+----
You can also use this function to request information about
the server itself.
.OPTIONS "*"
-
[source,erlang]
+----
StreamRef = gun:options(ConnPid, "*").
+----
==== Requests with an arbitrary method
-The `gun:request/{4,5,6}` function can be used to send requests
+The `gun:request/4,5,6` function can be used to send requests
with a configurable method name. It is mostly useful when you
need a method that Gun does not understand natively.
.Example of a TRACE request
-
[source,erlang]
+----
gun:request(ConnPid, "TRACE", "/", [
- {<<"max-forwards">>, "30"}
+ {<<"max-forwards">>, "30"}
]).
+----
=== Processing responses
@@ -242,36 +254,35 @@ You can receive messages directly, or you can use the _await_
functions to let Gun receive them for you.
.Receiving a response using receive
-
[source,erlang]
----
print_body(ConnPid, MRef) ->
- StreamRef = gun:get(ConnPid, "/"),
- receive
- {gun_response, ConnPid, StreamRef, fin, Status, Headers} ->
- no_data;
- {gun_response, ConnPid, StreamRef, nofin, Status, Headers} ->
- receive_data(ConnPid, MRef, StreamRef);
- {'DOWN', MRef, process, ConnPid, Reason} ->
- error_logger:error_msg("Oops!"),
- exit(Reason)
- after 1000 ->
- exit(timeout)
- end.
+ StreamRef = gun:get(ConnPid, "/"),
+ receive
+ {gun_response, ConnPid, StreamRef, fin, Status, Headers} ->
+ no_data;
+ {gun_response, ConnPid, StreamRef, nofin, Status, Headers} ->
+ receive_data(ConnPid, MRef, StreamRef);
+ {'DOWN', MRef, process, ConnPid, Reason} ->
+ error_logger:error_msg("Oops!"),
+ exit(Reason)
+ after 1000 ->
+ exit(timeout)
+ end.
receive_data(ConnPid, MRef, StreamRef) ->
- receive
- {gun_data, ConnPid, StreamRef, nofin, Data} ->
- io:format("~s~n", [Data]),
- receive_data(ConnPid, MRef, StreamRef);
- {gun_data, ConnPid, StreamRef, fin, Data} ->
- io:format("~s~n", [Data]);
- {'DOWN', MRef, process, ConnPid, Reason} ->
- error_logger:error_msg("Oops!"),
- exit(Reason)
- after 1000 ->
- exit(timeout)
- end.
+ receive
+ {gun_data, ConnPid, StreamRef, nofin, Data} ->
+ io:format("~s~n", [Data]),
+ receive_data(ConnPid, MRef, StreamRef);
+ {gun_data, ConnPid, StreamRef, fin, Data} ->
+ io:format("~s~n", [Data]);
+ {'DOWN', MRef, process, ConnPid, Reason} ->
+ error_logger:error_msg("Oops!"),
+ exit(Reason)
+ after 1000 ->
+ exit(timeout)
+ end.
----
While it may seem verbose, using messages like this has the
@@ -283,29 +294,30 @@ at the same time.
You can also use Gun in a synchronous manner by using the _await_
functions.
-The `gun:await/{2,3,4}` function will wait until it receives
+The `gun:await/2,3,4` function will wait until it receives
a response to, a pushed resource related to, or data from
the given stream.
-When calling `gun:await/{2,3}` and not passing a monitor
+When calling `gun:await/2,3` and not passing a monitor
reference, one is automatically created for you for the
duration of the call.
-The `gun:await_body/{2,3,4}` works similarly, but returns the
+The `gun:await_body/2,3,4` works similarly, but returns the
body received. Both functions can be combined to receive the
response and its body sequentially.
.Receiving a response using await
-
[source,erlang]
+----
StreamRef = gun:get(ConnPid, "/"),
case gun:await(ConnPid, StreamRef) of
- {response, fin, Status, Headers} ->
- no_data;
- {response, nofin, Status, Headers} ->
- {ok, Body} = gun:await_body(ConnPid, StreamRef),
- io:format("~s~n", [Body])
+ {response, fin, Status, Headers} ->
+ no_data;
+ {response, nofin, Status, Headers} ->
+ {ok, Body} = gun:await_body(ConnPid, StreamRef),
+ io:format("~s~n", [Body])
end.
+----
=== Handling streams pushed by the server
@@ -323,26 +335,28 @@ The `gun_push` message contains both the new stream reference
and the stream reference of the original request.
.Receiving a pushed response using receive
-
[source,erlang]
+----
receive
- {gun_push, ConnPid, OriginalStreamRef, PushedStreamRef,
- Method, Host, Path, Headers} ->
- enjoy()
+ {gun_push, ConnPid, OriginalStreamRef, PushedStreamRef,
+ Method, Host, Path, Headers} ->
+ enjoy()
end.
+----
-If you use the `gun:await/{2,3,4}` function, however, Gun
+If you use the `gun:await/2,3,4` function, however, Gun
will use the original reference to identify the message but
will return a tuple that doesn't contain it.
.Receiving a pushed response using await
-
[source,erlang]
-{push, PushedStreamRef, Method, Host, Path, Headers}
- = gun:await(ConnPid, OriginalStreamRef).
+----
+{push, PushedStreamRef, Method, URI, Headers}
+ = gun:await(ConnPid, OriginalStreamRef).
+----
-The `PushedStreamRef` variable can then be used with `gun:await_body/{2,3,4}`
-if needed.
+The `PushedStreamRef` variable can then be used with `gun:await/2,3,4`
+and `gun:await_body/2,3,4`.
=== Flushing unwanted messages
@@ -352,14 +366,16 @@ can use it to get rid of all messages related to a connection,
or just the messages related to a stream.
.Flush all messages from a Gun connection
-
[source,erlang]
+----
gun:flush(ConnPid).
+----
.Flush all messages from a specific stream
-
[source,erlang]
+----
gun:flush(StreamRef).
+----
=== Redirecting responses to a different process
@@ -367,7 +383,8 @@ Gun allows you to specify which process will handle responses
to a request via the `reply_to` request option.
.GET "/organizations/ninenines" to a different process
-
[source,erlang]
+----
StreamRef = gun:get(ConnPid, "/organizations/ninenines", [],
- #{reply_to => Pid}).
+ #{reply_to => Pid}).
+----
diff --git a/docs/en/gun/1.0/guide/http/index.html b/docs/en/gun/1.0/guide/http/index.html
index 2753588e..6c32ab5d 100644
--- a/docs/en/gun/1.0/guide/http/index.html
+++ b/docs/en/gun/1.0/guide/http/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: HTTP
@@ -71,7 +69,7 @@ communicating with an HTTP/1.1 or HTTP/2 server.
Every time a request is initiated, Gun creates a stream.
A stream reference uniquely identifies a set of request and
-response(s) and must be used to perform additional operations
+response and must be used to perform additional operations
with a stream or to identify its messages.
Stream references use the Erlang reference data type and
are therefore unique.
@@ -107,7 +105,7 @@ header if it has not been provided in the request arguments.
handling of responses will be explained further on.
It is not possible to send a request body with a GET or HEAD
request.
@@ -153,7 +151,7 @@ request.
POST, PUT and PATCH
HTTP defines three methods to create or update a resource.
POST is generally used when the resource identifier (URI) isn’t known
-in advance when creating the resource. POST can also be used to
+in advance when creating a resource. POST can also be used to
replace an existing resource, although PUT is more appropriate
in that situation.
PUT creates or replaces a resource identified by the URI.
@@ -163,7 +161,7 @@ request body. The PATCH method can be used when this is not
desirable. The request body of a PATCH method may be a partial
representation or a list of instructions on how to update the
resource.
-
The gun:post/{4,5}, gun:put/{4,5} and gun:patch/{4,5} functions
+
The gun:post/4,5, gun:put/4,5 and gun:patch/4,5 functions
take a body as their fourth argument. These functions do
not require any body-specific header to be set, although
it is always recommended to set the content-type header.
@@ -179,7 +177,7 @@ http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
The gun:post/3, gun:put/3 and gun:patch/3 functions
do not take a body in their arguments. If a body is to be
@@ -200,8 +198,8 @@ http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
The atom fin indicates this is the last chunk of data to
@@ -209,7 +207,6 @@ be sent. You can call the gun:data/4 function as many
times as needed until you have sent the entire body. The
last call must use fin and all the previous calls must
use nofin. The last chunk may be empty.
The gun:request/{4,5,6} function can be used to send requests
+
The gun:request/4,5,6 function can be used to send requests
with a configurable method name. It is mostly useful when you
need a method that Gun does not understand natively.
@@ -291,7 +288,7 @@ by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
While it may seem verbose, using messages like this has the
advantage of never locking your process, allowing you to
easily debug your code. It also allows you to start more than
@@ -352,13 +349,13 @@ one connection and concurrently perform queries on all of them
at the same time.
You can also use Gun in a synchronous manner by using the await
functions.
-
The gun:await/{2,3,4} function will wait until it receives
+
The gun:await/2,3,4 function will wait until it receives
a response to, a pushed resource related to, or data from
the given stream.
-
When calling gun:await/{2,3} and not passing a monitor
+
When calling gun:await/2,3 and not passing a monitor
reference, one is automatically created for you for the
duration of the call.
-
The gun:await_body/{2,3,4} works similarly, but returns the
+
The gun:await_body/2,3,4 works similarly, but returns the
body received. Both functions can be combined to receive the
response and its body sequentially.
If you use the gun:await/{2,3,4} function, however, Gun
+
If you use the gun:await/2,3,4 function, however, Gun
will use the original reference to identify the message but
will return a tuple that doesn’t contain it.
@@ -410,10 +407,10 @@ will return a tuple that doesn’t contain it.
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
-
+ #{reply_to=>Pid}).
diff --git a/docs/en/gun/1.0/guide/index.html b/docs/en/gun/1.0/guide/index.html
index f7e4b26e..cb30dd5b 100644
--- a/docs/en/gun/1.0/guide/index.html
+++ b/docs/en/gun/1.0/guide/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Gun User Guide
diff --git a/docs/en/gun/1.0/guide/introduction.asciidoc b/docs/en/gun/1.0/guide/introduction.asciidoc
index f437769a..f7cd9c10 100644
--- a/docs/en/gun/1.0/guide/introduction.asciidoc
+++ b/docs/en/gun/1.0/guide/introduction.asciidoc
@@ -1,6 +1,9 @@
+[[introduction]]
== Introduction
-Gun is an Erlang HTTP client with support for HTTP/1.1, HTTP/2 and Websocket.
+Gun is an HTTP client for Erlang/OTP.
+
+Gun supports the HTTP/2, HTTP/1.1 and Websocket protocols.
=== Prerequisites
@@ -9,12 +12,33 @@ protocols is required in order to read this guide.
=== Supported platforms
-Gun is tested and supported on Linux.
+Gun is tested and supported on Linux, FreeBSD, Windows and OSX.
+
+Gun is developed for Erlang/OTP 19.0 and newer.
+
+=== License
-Gun is developed for Erlang 19+.
+Gun uses the ISC License.
-Gun may be compiled on earlier Erlang versions with small source code
-modifications but there is no guarantee that it will work as intended.
+----
+Copyright (c) 2013-2018, Loïc Hoguin
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+----
+
+=== Versioning
+
+Gun uses http://semver.org/[Semantic Versioning 2.0.0].
=== Conventions
@@ -26,7 +50,3 @@ to lowercase, and expects your application to provide lowercase header
names.
The same applies to any other case insensitive value.
-
-=== Versioning
-
-Gun uses [Semantic Versioning 2.0.0](http://semver.org/).
diff --git a/docs/en/gun/1.0/guide/introduction/index.html b/docs/en/gun/1.0/guide/introduction/index.html
index 5a59d78a..6a3ed2e7 100644
--- a/docs/en/gun/1.0/guide/introduction/index.html
+++ b/docs/en/gun/1.0/guide/introduction/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Introduction
@@ -64,7 +62,8 @@
Introduction
-
Gun is an Erlang HTTP client with support for HTTP/1.1, HTTP/2 and Websocket.
+
Gun is an HTTP client for Erlang/OTP.
+
Gun supports the HTTP/2, HTTP/1.1 and Websocket protocols.
Prerequisites
@@ -75,10 +74,36 @@ protocols is required in order to read this guide.
Supported platforms
-
Gun is tested and supported on Linux.
-
Gun is developed for Erlang 19+.
-
Gun may be compiled on earlier Erlang versions with small source code
-modifications but there is no guarantee that it will work as intended.
+
Gun is tested and supported on Linux, FreeBSD, Windows and OSX.
+
Gun is developed for Erlang/OTP 19.0 and newer.
+
+
+
+
License
+
+
Gun uses the ISC License.
+
+
+
Copyright (c) 2013-2018, Loïc Hoguin <essen@ninenines.eu>
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
diff --git a/docs/en/gun/1.0/guide/protocols.asciidoc b/docs/en/gun/1.0/guide/protocols.asciidoc
index ae7705ff..2c4fd10e 100644
--- a/docs/en/gun/1.0/guide/protocols.asciidoc
+++ b/docs/en/gun/1.0/guide/protocols.asciidoc
@@ -1,3 +1,4 @@
+[[protocols]]
== Supported protocols
This chapter describes the protocols supported and the
@@ -10,31 +11,36 @@ sends a request, the server sends back a response.
Gun provides convenience functions for performing GET, HEAD,
OPTIONS, POST, PATCH, PUT, and DELETE requests. All these
-functions are aliases of `gun:request/{4,5,6}` for each respective
+functions are aliases of `gun:request/4,5,6` for the respective
methods. Gun also provides a `gun:data/4` function for streaming
the request body.
+Gun will send a `gun_inform` message for every intermediate
+informational responses received. They will always be sent
+before the `gun_response` message.
+
Gun will send a `gun_response` message for every response
received, followed by zero or more `gun_data` messages for
-the response body. If something goes wrong, a `gun_error`
+the response body, which is optionally terminated by a
+`gun_trailers` message. If something goes wrong, a `gun_error`
will be sent instead.
Gun provides convenience functions for dealing with messages.
-The `gun:await/{2,3,4}` function waits for a response to the given
-request, and the `gun:await_body/{2,3,4}` function for the
-response's body. The `gun:flush/1` function can be used to clear all
+The `gun:await/2,3,4` function waits for a response to the given
+request, and the `gun:await_body/2,3,4` function for the
+response body. The `gun:flush/1` function can be used to clear all
messages related to a request or a connection from the mailbox
-of the process.
+of the calling process.
The function `gun:cancel/2` can be used to silence the
response to a request previously sent if it is no longer
needed. When using HTTP/1.1 there is no multiplexing so
Gun will have to receive the response fully before any
-other response can be received.
+other responses can be received.
Finally, Gun can upgrade an HTTP/1.1 connection to Websocket.
-It provides the `gun:ws_upgrade/{2,3,4}` function for that
-purpose. A `gun_ws_upgrade` message will be sent on success;
+It provides the `gun:ws_upgrade/2,3,4` function for that
+purpose. A `gun_upgrade` message will be sent on success;
a `gun_response` message otherwise.
=== HTTP/2
@@ -42,25 +48,26 @@ a `gun_response` message otherwise.
HTTP/2 is a binary protocol based on HTTP, compatible with
the HTTP semantics, that reduces the complexity of parsing
requests and responses, compresses the HTTP headers and
-allows the server to push multiple responses to a single
-request.
+allows the server to push additional resources along with
+the normal response to the original request.
The HTTP/2 interface is very similar to HTTP/1.1, so this
section instead focuses on the differences in the interface
for the two protocols.
-Because a HTTP/2 server can push multiple responses to a
-single request, Gun might send `gun_push` messages for
-every push received. They can be ignored safely if they
-are not needed.
+Gun will send `gun_push` messages for every push received.
+They will always be sent before the `gun_response` message.
+They can be ignored safely if they are not needed, or they
+can be canceled.
The `gun:cancel/2` function will use the HTTP/2 stream
cancellation mechanism which allows Gun to inform the
server to stop sending a response for this particular
request, saving resources.
-It is not possible to upgrade an HTTP/2 connection to Websocket
-due to protocol limitations.
+It is not currently possible to upgrade an HTTP/2 connection
+to Websocket. Support for this will be added in a future
+release.
=== Websocket
@@ -110,10 +117,11 @@ current protocol.
|===
| Message | HTTP/1.1 | HTTP/2 | Websocket
| gun_push | no | yes | no
+| gun_inform | yes | yes | no
| gun_response | yes | yes | no
| gun_data | yes | yes | no
-| gun_error (StreamRef) | yes | yes | no
+| gun_trailers | yes | yes | no
| gun_error | yes | yes | yes
-| gun_ws_upgrade | yes | no | no
+| gun_upgrade | yes | no | no
| gun_ws | no | no | yes
|===
diff --git a/docs/en/gun/1.0/guide/protocols/index.html b/docs/en/gun/1.0/guide/protocols/index.html
index b94891f0..00d70ad6 100644
--- a/docs/en/gun/1.0/guide/protocols/index.html
+++ b/docs/en/gun/1.0/guide/protocols/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Supported protocols
@@ -73,27 +71,31 @@ operations available to them.
sends a request, the server sends back a response.
Gun provides convenience functions for performing GET, HEAD,
OPTIONS, POST, PATCH, PUT, and DELETE requests. All these
-functions are aliases of gun:request/{4,5,6} for each respective
+functions are aliases of gun:request/4,5,6 for the respective
methods. Gun also provides a gun:data/4 function for streaming
the request body.
+
Gun will send a gun_inform message for every intermediate
+informational responses received. They will always be sent
+before the gun_response message.
Gun will send a gun_response message for every response
received, followed by zero or more gun_data messages for
-the response body. If something goes wrong, a gun_error
+the response body, which is optionally terminated by a
+gun_trailers message. If something goes wrong, a gun_error
will be sent instead.
Gun provides convenience functions for dealing with messages.
-The gun:await/{2,3,4} function waits for a response to the given
-request, and the gun:await_body/{2,3,4} function for the
-response’s body. The gun:flush/1 function can be used to clear all
+The gun:await/2,3,4 function waits for a response to the given
+request, and the gun:await_body/2,3,4 function for the
+response body. The gun:flush/1 function can be used to clear all
messages related to a request or a connection from the mailbox
-of the process.
+of the calling process.
The function gun:cancel/2 can be used to silence the
response to a request previously sent if it is no longer
needed. When using HTTP/1.1 there is no multiplexing so
Gun will have to receive the response fully before any
-other response can be received.
+other responses can be received.
Finally, Gun can upgrade an HTTP/1.1 connection to Websocket.
-It provides the gun:ws_upgrade/{2,3,4} function for that
-purpose. A gun_ws_upgrade message will be sent on success;
+It provides the gun:ws_upgrade/2,3,4 function for that
+purpose. A gun_upgrade message will be sent on success;
a gun_response message otherwise.
@@ -103,21 +105,22 @@ a gun_response message otherwise.
HTTP/2 is a binary protocol based on HTTP, compatible with
the HTTP semantics, that reduces the complexity of parsing
requests and responses, compresses the HTTP headers and
-allows the server to push multiple responses to a single
-request.
+allows the server to push additional resources along with
+the normal response to the original request.
The HTTP/2 interface is very similar to HTTP/1.1, so this
section instead focuses on the differences in the interface
for the two protocols.
-
Because a HTTP/2 server can push multiple responses to a
-single request, Gun might send gun_push messages for
-every push received. They can be ignored safely if they
-are not needed.
+
Gun will send gun_push messages for every push received.
+They will always be sent before the gun_response message.
+They can be ignored safely if they are not needed, or they
+can be canceled.
The gun:cancel/2 function will use the HTTP/2 stream
cancellation mechanism which allows Gun to inform the
server to stop sending a response for this particular
request, saving resources.
-
It is not possible to upgrade an HTTP/2 connection to Websocket
-due to protocol limitations.
+
It is not currently possible to upgrade an HTTP/2 connection
+to Websocket. Support for this will be added in a future
+release.
diff --git a/docs/en/gun/1.0/guide/start.asciidoc b/docs/en/gun/1.0/guide/start.asciidoc
index 6d93e2e8..09720dca 100644
--- a/docs/en/gun/1.0/guide/start.asciidoc
+++ b/docs/en/gun/1.0/guide/start.asciidoc
@@ -1,21 +1,21 @@
+[[start]]
== Starting and stopping
This chapter describes how to start and stop the Gun application.
=== Setting up
-Before Gun can be used it needs to be in Erlang's `ERL_LIBS` path variable.
-If you use `erlang.mk` or a similar build tool, you only need to specify
-Gun as a dependency to your application and the tool will take care
-of downloading Gun and setting up paths.
+Specify Gun as a dependency to your application in your favorite
+build tool.
-With `erlang.mk` this is done by adding `gun` to the `DEPS` variable
+With Erlang.mk this is done by adding `gun` to the `DEPS` variable
in your Makefile.
-.Adding Gun as an erlang.mk dependency
-
+.Adding Gun as an Erlang.mk dependency
[source,make]
+----
DEPS = gun
+----
=== Starting
@@ -23,45 +23,21 @@ Gun is an _OTP application_. It needs to be started before you can
use it.
.Starting Gun in an Erlang shell
-
[source,erlang]
----
1> application:ensure_all_started(gun).
-{ok,[ranch,crypto,cowlib,asn1,public_key,ssl,gun]}
+{ok,[crypto,cowlib,asn1,public_key,ssl,gun]}
----
=== Stopping
You can stop Gun using the `application:stop/1` function, however
-only Gun will be stopped. This is the equivalent of `application:start/1`.
+only Gun will be stopped. This is the reverse of `application:start/1`.
The `application_ensure_all_started/1` function has no equivalent for
stopping all applications.
.Stopping Gun
-
[source,erlang]
+----
application:stop(gun).
-
-=== Using Gun with releases
-
-An _OTP release_ starts applications automatically. All you need
-to do is to set up your application resource file so that Gun can
-be included in the release. The application resource file can be
-found in `ebin/your_application.app`, or in `src/your_application.app.src`
-if you are using a build tool like `erlang.mk`.
-
-The key you need to change is the `applications` key. By default
-it only includes `kernel` and `stdlib`. You need to add `gun` to
-that list.
-
-.Adding Gun to the application resource file
-
-[source,erlang]
-{applications, [
- kernel,
- stdlib,
- gun
-]}
-
-Do not put an extra comma at the end, the comma is a separator
-between the elements of the list.
+----
diff --git a/docs/en/gun/1.0/guide/start/index.html b/docs/en/gun/1.0/guide/start/index.html
index d2e8f0aa..6611c3ea 100644
--- a/docs/en/gun/1.0/guide/start/index.html
+++ b/docs/en/gun/1.0/guide/start/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Starting and stopping
@@ -68,14 +66,12 @@
Setting up
-
Before Gun can be used it needs to be in Erlang’s ERL_LIBS path variable.
-If you use erlang.mk or a similar build tool, you only need to specify
-Gun as a dependency to your application and the tool will take care
-of downloading Gun and setting up paths.
-
With erlang.mk this is done by adding gun to the DEPS variable
+
Specify Gun as a dependency to your application in your favorite
+build tool.
+
With Erlang.mk this is done by adding gun to the DEPS variable
in your Makefile.
You can stop Gun using the application:stop/1 function, however
-only Gun will be stopped. This is the equivalent of application:start/1.
+only Gun will be stopped. This is the reverse of application:start/1.
The application_ensure_all_started/1 function has no equivalent for
stopping all applications.
An OTP release starts applications automatically. All you need
-to do is to set up your application resource file so that Gun can
-be included in the release. The application resource file can be
-found in ebin/your_application.app, or in src/your_application.app.src
-if you are using a build tool like erlang.mk.
-
The key you need to change is the applications key. By default
-it only includes kernel and stdlib. You need to add gun to
-that list.
-
-
Adding Gun to the application resource file
-
-
{applications, [
- kernel,
- stdlib,
- gun
-]}
-
Do not put an extra comma at the end, the comma is a separator
-between the elements of the list.
-
-
diff --git a/docs/en/gun/1.0/guide/websocket.asciidoc b/docs/en/gun/1.0/guide/websocket.asciidoc
index f99dea70..cf32291f 100644
--- a/docs/en/gun/1.0/guide/websocket.asciidoc
+++ b/docs/en/gun/1.0/guide/websocket.asciidoc
@@ -1,10 +1,10 @@
+[[websocket]]
== Websocket
This chapter describes how to use the Gun client for
communicating with a Websocket server.
-@todo recovering from connection failure
-reconnecting to Websocket etc.
+// @todo recovering from connection failure, reconnecting to Websocket etc.
=== HTTP upgrade
@@ -14,33 +14,33 @@ HTTP/1.1 connections can be upgraded to Websocket, so you might
need to restrict the protocol to HTTP/1.1 if you are planning
to use Websocket over TLS.
-You must use the `gun_ws:upgrade/{2,3,4}` function to upgrade
+You must use the `gun:ws_upgrade/2,3,4` function to upgrade
to Websocket. This function can be called anytime after connection,
so you can send HTTP requests before upgrading to Websocket.
.Upgrade to Websocket
-
[source,erlang]
+----
gun:ws_upgrade(ConnPid, "/websocket").
+----
Gun will set all the necessary headers for performing the
Websocket upgrade, but you can specify additional headers
if needed. For example you can request a custom sub-protocol.
.Upgrade to Websocket and request a protocol
-
[source,erlang]
+----
gun:ws_upgrade(ConnPid, "/websocket", [
- {<<"sec-websocket-protocol">>, "mychat"}
+ {<<"sec-websocket-protocol">>, "mychat"}
]).
+----
-You can pass the Websocket options as part of the `gun:open/{2,3}`
+You can pass the Websocket options as part of the `gun:open/2,3`
call when opening the connection, or using the `gun:ws_upgrade/4`.
-The fourth argument is those same options. This function call
-will crash if the options are incorrect, unlike when passing
-them through `gun:open/{2,3}`.
+The fourth argument is those same options.
-When the upgrade succeeds, a `gun_ws_upgrade` message is sent.
+When the upgrade succeeds, a `gun_upgrade` message is sent.
If the server does not understand Websocket or refused the
upgrade, a `gun_response` message is sent. If Gun couldn't
perform the upgrade due to an error (for example attempting
@@ -52,21 +52,19 @@ a meaningful response which should be processed. In the
following example we however ignore it:
[source,erlang]
+----
receive
- {gun_ws_upgrade, ConnPid, ok, Headers} ->
- upgrade_success(ConnPid);
- {gun_response, ConnPid, _, _, Status, Headers} ->
- exit({ws_upgrade_failed, Status, Headers});
- {gun_error, ConnPid, StreamRef, Reason} ->
- exit({ws_upgrade_failed, Reason})
- %% More clauses here as needed.
+ {gun_upgrade, ConnPid, StreamRef, [<<"websocket">>], Headers} ->
+ upgrade_success(ConnPid, StreamRef);
+ {gun_response, ConnPid, _, _, Status, Headers} ->
+ exit({ws_upgrade_failed, Status, Headers});
+ {gun_error, ConnPid, StreamRef, Reason} ->
+ exit({ws_upgrade_failed, Reason})
+ %% More clauses here as needed.
after 1000 ->
- exit(timeout)
+ exit(timeout)
end.
-
-Note that you shouldn't use the `reply_to` request option
-for connections you plan to upgrade, because only the
-owner of the connection will receive messages about it.
+----
=== Sending data
@@ -74,27 +72,28 @@ Once the Websocket upgrade has completed successfully, you no
longer have access to functions for performing requests. You
can only send and receive Websocket messages.
-Use `gun:ws_send/2` to send one or more messages to the server.
-
-@todo Implement sending of N frames
+Use `gun:ws_send/2` to send messages to the server.
.Send a text frame
-
[source,erlang]
+----
gun:ws_send(ConnPid, {text, "Hello!"}).
-
-.Send a text frame, a binary frame and then close the connection
-
-[source,erlang]
-gun:ws_send(ConnPid, [
- {text, "Hello!"},
- {binary, BinaryValue},
- close
-]).
+----
+
+// @todo Implement sending of N frames
+//
+//.Send a text frame, a binary frame and then close the connection
+//[source,erlang]
+//----
+//gun:ws_send(ConnPid, [
+// {text, "Hello!"},
+// {binary, BinaryValue},
+// close
+//]).
+//----
Note that if you send a close frame, Gun will close the connection
-cleanly and will not attempt to reconnect afterwards, similar to
-calling `gun:shutdown/1`.
+cleanly and will not attempt to reconnect afterwards.
=== Receiving data
@@ -102,15 +101,17 @@ Gun sends an Erlang message to the owner process for every
Websocket message it receives.
[source,erlang]
+----
receive
- {gun_ws, ConnPid, Frame} ->
- handle_frame(ConnPid, Frame)
+ {gun_ws, ConnPid, StreamRef, Frame} ->
+ handle_frame(ConnPid, StreamRef, Frame)
end.
-
-@todo auto ping has not been implemented yet
-
-Gun will automatically send ping messages to the server to keep
-the connection alive, however if the connection dies and Gun has
-to reconnect it will not upgrade to Websocket automatically, you
-need to perform the operation when you receive the `gun_error`
-message.
+----
+
+// @todo auto ping has not been implemented yet
+//
+//Gun will automatically send ping messages to the server to keep
+//the connection alive, however if the connection dies and Gun has
+//to reconnect it will not upgrade to Websocket automatically, you
+//need to perform the operation when you receive the `gun_error`
+//message.
diff --git a/docs/en/gun/1.0/guide/websocket/index.html b/docs/en/gun/1.0/guide/websocket/index.html
index b34a290d..a77f1319 100644
--- a/docs/en/gun/1.0/guide/websocket/index.html
+++ b/docs/en/gun/1.0/guide/websocket/index.html
@@ -7,8 +7,6 @@
-
-
Nine Nines: Websocket
@@ -66,8 +64,6 @@
This chapter describes how to use the Gun client for
communicating with a Websocket server.
-
@todo recovering from connection failure
-reconnecting to Websocket etc.
HTTP upgrade
@@ -76,7 +72,7 @@ you must first request for the connection to be upgraded. Only
HTTP/1.1 connections can be upgraded to Websocket, so you might
need to restrict the protocol to HTTP/1.1 if you are planning
to use Websocket over TLS.
-
You must use the gun_ws:upgrade/{2,3,4} function to upgrade
+
You must use the gun:ws_upgrade/2,3,4 function to upgrade
to Websocket. This function can be called anytime after connection,
so you can send HTTP requests before upgrading to Websocket.
@@ -96,14 +92,12 @@ by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
You can pass the Websocket options as part of the gun:open/{2,3}
+
You can pass the Websocket options as part of the gun:open/2,3
call when opening the connection, or using the gun:ws_upgrade/4.
-The fourth argument is those same options. This function call
-will crash if the options are incorrect, unlike when passing
-them through gun:open/{2,3}.
-
When the upgrade succeeds, a gun_ws_upgrade message is sent.
+The fourth argument is those same options.
+
When the upgrade succeeds, a gun_upgrade message is sent.
If the server does not understand Websocket or refused the
upgrade, a gun_response message is sent. If Gun couldn’t
perform the upgrade due to an error (for example attempting
@@ -118,19 +112,16 @@ by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
Note that you shouldn’t use the reply_to request option
-for connections you plan to upgrade, because only the
-owner of the connection will receive messages about it.
@@ -139,8 +130,7 @@ owner of the connection will receive messages about it.
Once the Websocket upgrade has completed successfully, you no
longer have access to functions for performing requests. You
can only send and receive Websocket messages.
-
Use gun:ws_send/2 to send one or more messages to the server.
-
@todo Implement sending of N frames
+
Use gun:ws_send/2 to send messages to the server.
Send a text frame
gun:ws_send(ConnPid, {text, "Hello!"}).
-
-
Send a text frame, a binary frame and then close the connection
Note that if you send a close frame, Gun will close the connection
-cleanly and will not attempt to reconnect afterwards, similar to
-calling gun:shutdown/1.
+cleanly and will not attempt to reconnect afterwards.
@@ -175,15 +153,9 @@ by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
Gun will automatically send ping messages to the server to keep
-the connection alive, however if the connection dies and Gun has
-to reconnect it will not upgrade to Websocket automatically, you
-need to perform the operation when you receive the gun_error
-message.
This function waits for a message from the given stream and
+returns it as a tuple. An error will be returned should the
+process fail or a relevant message is not received within
+the specified duration.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+StreamRef
+
+
+
+Identifier of the stream for the original request.
+
+
+
+Timeout
+
+
+
+How long to wait for a message, in milliseconds.
+
+
+
+MonitorRef
+
+
+
+Monitor for the Gun connection process.
+
+
A monitor is automatically created for the duration of this
+call when one is not provided.
+
+
+
+
+
+
Return value
+
+
A number of different tuples can be returned. They correspond
+to the message of the same name and they contain the same
+elements minus the pid and stream reference. Error tuples
+may also be returned when a timeout or an error occur.
+Identifier of the stream for the original request.
+
+
+
+Timeout
+
+
+
+How long to wait for each message, in milliseconds.
+
+
+
+MonitorRef
+
+
+
+Monitor for the Gun connection process.
+
+
A monitor is automatically created for the duration of this
+call when one is not provided.
+
+
+
+
+
+
Return value
+
+
The body is returned, possibly with trailers if the
+request contained a te: trailers header. Error tuples
+may also be returned when a timeout or an error occur.
A monitor is automatically created for the duration of this
+call when one is not provided.
+
+
+
+
+
+
Return value
+
+
The protocol selected for this connection. It can be used
+to determine the capabilities of the server. Error tuples
+may also be returned when a timeout or an error occur.
The behavior of this function depends on the protocol
+selected.
+
HTTP/1.1 does not support this feature. Gun will simply
+silence the stream and stop relaying messages. Gun may
+also decide to close the connection if the response body
+is too large, to avoid wasting time and bandwidth.
+
HTTP/2 allows cancelling streams at any time.
+
This function is asynchronous. Messages related to this
+stream may still be sent after the function returns.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+StreamRef
+
+
+
+Identifier of the stream for the original request.
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
This function performs the same operation as
+gun:get(3), except the server will not
+send the resource representation, only the response’s status
+code and headers.
+
While servers are supposed to send the same headers as for
+a GET request, they sometimes will not. For example the
+content-length header may be dropped from the response.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
The pid of the newly created Gun process is returned.
+Note that this does not indicate that the connection
+has been successfully opened; the gun_up(3)
+message will be sent for that.
Open a connection to the given Unix domain socket.
+
+
+
+
Arguments
+
+
+
+SocketPath
+
+
+
+Path to the Unix domain socket to connect to.
+
+
+
+Opts
+
+
+
+Options for this connection.
+
+
+
+
+
+
+
Return value
+
+
The pid of the newly created Gun process is returned.
+Note that this does not indicate that the connection
+has been successfully opened; the gun_up(3)
+message will be sent for that.
Query the capabilities of the server or a resource.
+
The special path "*" can be used to obtain information about
+the server as a whole. Any other path will return information
+about that resource specifically.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
The behavior of this function varies depending on whether
+a body is provided.
+
The function patch/3 expects either a content-length
+or content-type header to indicate that a body will be
+sent afterwards. The body can then be sent using
+gun:data(3).
+
The function patch/4,5 sends the entire request, including
+the request body, immediately. It is therefore not possible
+to use gun:data(3) after that. You
+should provide a content-type header. Gun will set the
+content-length header automatically.
+
The body sent in this request should be a patch document
+with instructions on how to update the resource.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+Body
+
+
+
+Request body.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
Process the enclosed representation according to a resource’s
+own semantics.
+
The behavior of this function varies depending on whether
+a body is provided.
+
The function post/3 expects either a content-length
+or content-type header to indicate that a body will be
+sent afterwards. The body can then be sent using
+gun:data(3).
+
The function post/4,5 sends the entire request, including
+the request body, immediately. It is therefore not possible
+to use gun:data(3) after that. You
+should provide a content-type header. Gun will set the
+content-length header automatically.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+Body
+
+
+
+Request body.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
The behavior of this function varies depending on whether
+a body is provided.
+
The function put/3 expects either a content-length
+or content-type header to indicate that a body will be
+sent afterwards. The body can then be sent using
+gun:data(3).
+
The function put/4,5 sends the entire request, including
+the request body, immediately. It is therefore not possible
+to use gun:data(3) after that. You
+should provide a content-type header. Gun will set the
+content-length header automatically.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+Body
+
+
+
+Request body.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
This is a general purpose function that should only be
+used when other method-specific functions do not apply.
+
The behavior of this function varies depending on whether
+a body is provided.
+
The function request/4 expects either a content-length
+or content-type header to indicate that a body will be
+sent afterwards. Gun will assume the request has no body
+otherwise. The body can then be sent using
+gun:data(3).
+
The function request/5,6 sends the entire request, including
+the request body, immediately. It is therefore not possible
+to use gun:data(3) after that. You
+should provide a content-type header. Gun will set the
+content-length header automatically.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Method
+
+
+
+Method to be used for the request.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+Body
+
+
+
+Request body.
+
+
+
+ReqOpts
+
+
+
+Request options.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
The behavior of this function depends on the protocol
+selected.
+
HTTP/1.1 cannot handle Websocket and HTTP requests
+concurrently. The upgrade, if successful, will result
+in the complete takeover of the connection. Any
+subsequent HTTP requests will be rejected.
+
Gun does not currently support Websocket over HTTP/2.
+
By default Gun will take the Websocket options from
+the connection’s ws_opts.
+
+
+
+
Arguments
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Path
+
+
+
+Path to the resource.
+
+
+
+Headers
+
+
+
+Additional request headers.
+
+
+
+WsOpts
+
+
+
+Configuration for the Websocket protocol.
+
+
+
+
+
+
+
Return value
+
+
A reference that identifies the newly created stream is
+returned. It is this reference that must be passed in
+subsequent calls and will be received in messages related
+to this new stream.
- Options specific to the HTTP protocol. See below.
-
-
-
-http2_opts ⇒ http2_opts()
-
-
-
- Options specific to the HTTP/2 protocol. See below.
-
-
-
-protocols ⇒ [http | http2]
-
-
+
Connection:
+
+
- Ordered list of preferred protocols. When the transport is tcp,
- this list must contain exactly one protocol. When the transport
- is ssl, this list must contain at least one protocol and will be
- used using the ALPN protocol negotiation method. When the server
- does not support ALPN then http will always be used. Defaults to
- [http] when the transport is tcp, and [http2, http] when the
- transport is ssl.
+gun:open(3) - Open a connection to the given host and port
-
-
-retry ⇒ non_neg_integer()
-
-
+
+
- Number of times Gun will try to reconnect on failure before giving up.
- Defaults to 5.
+gun:open_unix(3) - Open a connection to the given Unix domain socket
-
-
-retry_timeout ⇒ pos_integer()
-
-
+
+
- Time between retries in milliseconds. Defaults to 5000.
+gun:close(3) - Brutally close the connection
-
-
-trace ⇒ boolean()
-
-
+
+
- Whether to enable dbg tracing of the connection process. Should
- only be used during debugging. Defaults to false.
+gun:info(3) - Obtain information about the connection
-
-
-transport ⇒ tcp | ssl
-
-
+
+
+
Requests:
+
+
- Whether to use SSL or plain TCP. The default varies depending on the
- port used. Port 443 defaults to ssl. All other ports default to tcp.
+gun:get(3) - Get a resource representation
-
-
-transport_opts ⇒ proplists:proplist()
-
-
+
+
- Transport options. They are TCP options or SSL options depending on
- the selected transport.
+gun:head(3) - Get headers of a resource representation
-
-
-ws_opts ⇒ ws_opts()
-
-
+
+
- Options specific to the Websocket protocol. See below.
+gun:options(3) - Query the capabilities of the server or a resource
-
-
-
-
-
http_opts() = map()
-
Configuration for the HTTP protocol.
-
The following keys are defined:
-
-
-keepalive ⇒ timeout()
-
-
+
+
- Time between pings in milliseconds. Since the HTTP protocol has
- no standardized way to ping the server, Gun will simply send an
- empty line when the connection is idle. Gun only makes a best
- effort here as servers usually have configurable limits to drop
- idle connections. Use infinity to disable. Defaults to 5000.
+gun:patch(3) - Apply a set of changes to a resource
- A function that will be applied to all header names before they
- are sent to the server. Gun assumes that all header names are in
- lower case. This function is useful if you, for example, need to
- re-case header names in the event that the server incorrectly
- considers header name case to be significant.
+gun:post(3) - Process the enclosed representation according to a resource’s own semantics
-
-
-version ⇒ HTTP/1.1 | HTTP/1.0
-
-
+
+
- HTTP version to use. Defaults to HTTP/1.1.
+gun:put(3) - Create or replace a resource
-
-
-
-
-
http2_opts() = map()
-
Configuration for the HTTP/2 protocol.
-
The following keys are defined:
-
-
-keepalive ⇒ pos_integer()
-
-
+
+
- Time between pings in milliseconds. Defaults to 5000.
+gun:delete(3) - Delete a resource
-
-
-
-
-
req_opts() = map()
-
Configuration for a particular request.
-
The following keys are defined:
-
-
-reply_to ⇒ pid()
-
-
+
+
- The pid of a process that is responsible for the response handling.
+gun:request(3) - Perform the given request
-
-
-
-
-
ws_opts() = map()
-
Configuration for the Websocket protocol.
-
The following keys are defined:
-
-
-compress ⇒ boolean()
-
-
+
+
- Whether to enable permessage-deflate compression. This does
- not guarantee that compression will be used as it is the
- server that ultimately decides. Defaults to false.
+gun:data(3) - Stream the body of a request
-
-
-
-
-
-
-
Messages
-
-
Calling functions from this module may result in the following
-messages being sent.
-
-
{gun_up, ConnPid, Protocol}
-
-
-ConnPid = pid()
-
-
+
+
+
Messages:
+
+
-The pid of the Gun connection process.
+gun:await(3) - Wait for a response
-
-
-Protocol = http | http2
-
-
+
+
-The protocol selected for this connection.
+gun:await_body(3) - Wait for the complete response body
-
-
-
The connection is up.
-
This message informs the owner process that the connection or
-reconnection completed.
-
The protocol selected during the connection is sent in this
-message. It can be used to determine the capabilities of the
-server.
-
Gun will now start processing the messages it received while
-waiting for the connection to be up. If this is a reconnection,
-then this may not be desirable for all requests. Those requests
-should be cancelled when the connection goes down, and any
-subsequent messages ignored.
-The pid of the Gun connection process.
+gun:await(3) - Wait for the connection to be up
-
-
-Protocol = http | http2 | ws
-
-
+
+
-The protocol in use when the connection was lost.
+gun:flush(3) - Flush all messages related to a connection or a stream
-
-
-Reason = normal | closed | {error, atom()}
-
-
+
+
+
Streams:
+
+
-The reason for the loss of the connection.
+gun:cancel(3) - Cancel the given stream
-
-
-KilledStreams = [reference()]
-
-
+
+
+
Websocket:
+
+
-List of streams that have been brutally terminated.
+gun:ws_upgrade(3) - Upgrade to Websocket
-
-
-UnprocessedStreams = [reference()]
-
-
+
+
-List of streams that have not been processed by the server.
+gun:ws_send(3) - Send Websocket frames
-
-
-
The connection is down.
-
This message informs the owner process that the connection is
-currently down. Gun will automatically attempt to reconnect
-depending on the retry and retry_timeout options.
-
The reason of the termination is there for debugging purposes
-only. You should not rely on this value to know what streams
-were processed or completed.
-
The killed streams are the active streams that did not complete
-before the closing of the connection. Whether they can be retried
-safely depends on the protocol used and the idempotence property
-of the requests.
-
The unprocessed streams are streams that the server did not
-start processing yet. They may be retried safely depending on
-what streams were killed before.
-
When the connection goes back up, Gun will not attempt to retry
-requests. It will also not upgrade to Websocket automatically
-if that was the protocol in use when the connection was lost.
This message can only be sent when the protocol is HTTP/2.
-
@todo I fear we also need the scheme; resource is identified by URI
-@todo Perhaps we really should send the URI entirely, because cache
-@todo relies on URI to work and this feature is for caching…
-@todo Not sure why Method is there, spec says it is only for GET
-The pid of the Gun connection process.
+gun_inform(3) - Informational response
-
-
-StreamRef = reference()
-
-
+
+
-Identifier of the stream initiated by the owner process.
+gun_response(3) - Response
-
-
-IsFin = fin | nofin
-
-
+
+
-Whether this message terminates the response.
+gun_data(3) - Response body
-
-
-Status = binary()
-
-
+
+
-Status line for the response.
+gun_trailers(3) - Response trailers
-
-
-Headers = [{binary(), binary()}]
-
-
+
+
+
Websocket:
+
+
-Headers sent with the response.
+gun_ws(3) - Websocket frame
-
-
-
A response to an HTTP request.
+
+
+
The response messages will be sent to the process that opened
+the connection by default. The reply_to request option can
+be used to redirect request-specific messages to a different
+process.
The default value is given next to the option name:
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-StreamRef = reference()
+keepalive (5000)
-Identifier of the stream this data belongs to.
+Time between pings in milliseconds. Since the HTTP protocol has
+no standardized way to ping the server, Gun will simply send an
+empty line when the connection is idle. Gun only makes a best
+effort here as servers usually have configurable limits to drop
+idle connections. Use infinity to disable.
-IsFin = fin | nofin
+transform_header_name - see below
-Whether this message terminates the response.
+A function that will be applied to all header names before they
+are sent to the server. Gun assumes that all header names are in
+lower case. This function is useful if you, for example, need to
+re-case header names in the event that the server incorrectly
+considers the case of header names to be significant.
-Data = binary()
+version ('HTTP/1.1')
-Data from the stream.
+HTTP version to use.
-
Data associated with a stream.
-
The stream in question can be either one initiated by the owner
-process or a stream initiated by the server through the push
-mechanism. In any case a gun_response or a gun_push message
-will be sent before any gun_data message.
-
{gun_error, ConnPid, StreamRef, Reason}
+
http2_opts()
+
+
+
http2_opts() :: #{
+ keepalive=>timeout()
+}
+
Configuration for the HTTP/2 protocol.
+
The default value is given next to the option name:
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-StreamRef = reference()
+keepalive (5000)
-Identifier of the stream this error relates to.
-
-
-
-Reason = any()
-
-
-
-Error reason.
+Time between pings in milliseconds.
-Headers sent with the response.
+Options specific to the HTTP/2 protocol.
-
-
Successful upgrade to the Websocket protocol.
-
-
-
{gun_ws, ConnPid, Frame}
-
-ConnPid = pid()
+protocols - see below
-The pid of the Gun connection process.
+Ordered list of preferred protocols. When the transport is tcp,
+this list must contain exactly one protocol. When the transport
+is tls, this list must contain at least one protocol and will be
+used to negotiate a protocol via ALPN. When the server does not
+support ALPN then http will always be used. Defaults to
+[http] when the transport is tcp, and [http2, http] when the
+transport is tls.
-Frame = @todo
+retry (5)
-Frame.
+Number of times Gun will try to reconnect on failure before giving up.
-Host to connect to.
+Time between retries in milliseconds.
-Port = inet:port_number()
+trace (false)
-Port to connect to.
+Whether to enable dbg tracing of the connection process. Should
+only be used during debugging.
-Opts = opts()
+transport - see below
-Options for this connection.
+Whether to use TLS or plain TCP. The default varies depending on the
+port used. Port 443 defaults to tls. All other ports default to tcp.
-ConnPid = pid()
+transport_opts ([])
-The pid of the Gun connection process.
+Transport options. They are TCP options or TLS options depending on
+the selected transport.
-Reason = any()
+ws_opts (#{})
-Error reason. @todo really any?
+Options specific to the Websocket protocol.
-
Open a connection to the given host and port.
-
close(ConnPid) → ok
+
req_opts()
+
+
+
req_opts() :: #{
+ reply_to=>pid()
+}
+
Configuration for a particular request.
+
The default value is given next to the option name:
-ConnPid = pid()
+reply_to (self())
-The pid of the Gun connection process.
+The pid of the process that will receive the response messages.
-
Brutally close the connection.
-
shutdown(ConnPid) → ok
+
ws_opts()
+
+
+
ws_opts() :: #{
+ compress=>boolean()
+}
+
Configuration for the Websocket protocol.
+
The default value is given next to the option name:
-ConnPid = pid()
+compress ⇒ boolean()
-The pid of the Gun connection process.
+Whether to enable permessage-deflate compression. This does
+not guarantee that compression will be used as it is the
+server that ultimately decides. Defaults to false.
-
Gracefully close the connection.
-
A monitor can be used to be notified when the connection is
-effectively closed.
This function performs the same operation as get/{2,3} except
-the server will not send the resource representation, only the
-response’s status line and headers.
-
While servers should send the same headers they would if the
-request was a GET, like content-length, it is not always
-the case and differences may exist.
Obtain information about the capabilities of the server or of a resource.
-
The special path "*" can be used to obtain information about
-the server as a whole. Any other path will return information
-about the resource only.
-
-
-
patch(ConnPid, Path, Headers) → StreamRef
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-Path = iodata()
-
-
-
-Path to the resource.
-
-
-
-Headers = [{binary(), iodata()}]
-
-
-
-Additional request headers.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream for this request.
-
-
-
-
Request that a set of changes be applied to the resource.
-
This function expects either content-length or content-type
-to be set to know a body is going to be sent afterwards.
-Gun will assume the request has no body otherwise. It is
-highly recommended to set both when possible.
-
The body sent in this request should be a patch document
-with instructions on how to update the resource.
-
You can use the gun:data/4 function to send the body, if any.
Request that a set of changes be applied to the resource.
-
It is highly recommended to set the content-type header
-to inform the server what media type the body contains.
-Gun will automatically set the content-length header.
-
The body sent in this request should be a patch document
-with instructions on how to update the resource.
-
The complete request is sent when calling this function.
-It is not possible to stream more of the body after
-calling it.
-
-
-
post(ConnPid, Path, Headers) → StreamRef
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-Path = iodata()
-
-
-
-Path to the resource.
-
-
-
-Headers = [{binary(), iodata()}]
-
-
-
-Additional request headers.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream for this request.
-
-
-
-
Process the enclosed representation according to the resource’s own semantics.
-
This function expects either content-length or content-type
-to be set to know a body is going to be sent afterwards.
-Gun will assume the request has no body otherwise. It is
-highly recommended to set both when possible.
-
The body sent in this request will be processed
-according to the resource’s own semantics. A new
-resource may be created as a result, and may be
-located at a different URI.
-
You can use the gun:data/4 function to send the body, if any.
Process the enclosed representation according to the resource’s own semantics.
-
It is highly recommended to set the content-type header
-to inform the server what media type the body contains.
-Gun will automatically set the content-length header.
-
The body sent in this request will be processed
-according to the resource’s own semantics. A new
-resource may be created as a result, and may be
-located at a different URI.
-
The complete request is sent when calling this function.
-It is not possible to stream more of the body after
-calling it.
-
-
-
put(ConnPid, Path, Headers) → StreamRef
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-Path = iodata()
-
-
-
-Path to the resource.
-
-
-
-Headers = [{binary(), iodata()}]
-
-
-
-Additional request headers.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream for this request.
-
-
-
-
Create or replace a resource.
-
The body of the request is the entire representation of the resource.
-
This function expects either content-length or content-type
-to be set to know a body is going to be sent afterwards.
-Gun will assume the request has no body otherwise. It is
-highly recommended to set both when possible.
-
You can use the gun:data/4 function to send the body, if any.
The body of the request is the entire representation of the resource.
-
It is highly recommended to set the content-type header
-to inform the server what media type the body contains.
-Gun will automatically set the content-length header.
-
The complete request is sent when calling this function.
-It is not possible to stream more of the body after
-calling it.
This is a general purpose function that should only be used
-when existing method-specific functions don’t apply.
-
This function expects either content-length or content-type
-to be set to know a body is going to be sent afterwards.
-Gun will assume the request has no body otherwise. It is
-highly recommended to set both when possible.
-
You can use the gun:data/4 function to send the body, if any.
This is a general purpose function that should only be used
-when existing method-specific functions don’t apply.
-
It is highly recommended to set the content-type header
-to inform the server what media type the body contains.
-Gun will automatically set the content-length header.
-
The complete request is sent when calling this function.
-It is not possible to stream more of the body after
-calling it.
-
-
-
data(ConnPid, StreamRef, IsFin, Data) → ok
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream this data belongs to.
-
-
-
-IsFin = fin | nofin
-
-
-
-Whether this message terminates the request.
-
-
-
-Data = iodata()
-
-
-
-Data to be sent with the request.
-
-
-
-
Stream the body of a request.
-
@todo empty chunks
-
This function can only be used if the request identified by
-StreamRef came with headers indicating the presence of a
-body and that body not being given when creating the request.
-
All calls to this function must use nofin except for the
-last which must use fin to indicate the end of the request
-body.
-
Empty data is allowed regardless of the value of IsFin.
-Gun will not send empty data chunks unless required to
-indicate the request body is finished, however.
A monitor MonitorRef is automatically created for the duration of
-this call and an error will be returned if the Gun connection process
-terminates.
-
-
-
await(ConnPid, StreamRef, Timeout, MonitorRef) → tuple() — see below
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream to await messages from.
-
-
-
-Timeout = timeout()
-
-
-
-How long this function will wait for messages.
-
-
-
-MonitorRef = reference()
-
-
-
-Monitor reference for the Gun connection process.
-
-
-
-
Wait for a response message.
-
This function can be used when a synchronous handling of
-responses is desired. It will only return when a message
-for the given stream is received, on error or on timeout.
-
The return values are described in the next few subsections.
-
-
{response, IsFin, Status, Headers}
-
-
-IsFin = fin | nofin
-
-
-
-Whether this message terminates the response.
-
-
-
-Status = binary()
-
-
-
-Status line for the response.
-
-
-
-Headers = [{binary(), binary()}]
-
-
-
-Headers sent with the response.
-
-
-
-
Equivalent of a gun_response message.
-
-
-
{data, IsFin, Data}
-
-
-IsFin = fin | nofin
-
-
-
-Whether this message terminates the response.
-
-
-
-Data = binary()
-
-
-
-Data from the stream.
-
-
-
-
Equivalent of a gun_data message.
-
-
-
{push, NewStreamRef, URI, Headers}
-
-
-NewStreamRef = reference()
-
-
-
-Identifier of the stream being pushed.
-
-
-
-URI = binary()
-
-
-
-URI of the resource.
-
-
-
-Headers = [{binary(), binary()}]
-
-
-
-Headers @todo
-
-
-
-
Equivalent of a gun_push message.
-
@todo Same changes as gun_push
-
-
-
{error, Reason}
-
-
-Reason = any()
-
-
-
-Error reason. @todo any?
-
-
-
-
Equivalent of a gun_error message.
-
@todo I think we want to distinguish a stream error, a general error,
-@todo a DOWN and a timeout error
-Identifier of the stream to await messages from.
-
-
-
-Timeout = timeout()
-
-
-
-How long this function will wait for each message.
-
-
-
-MonitorRef = reference()
-
-
-
-Monitor reference for the Gun connection process.
-
-
-
-Body = binary()
-
-
-
-Body for the given stream.
-
-
-
-Reason = any()
-
-
-
-Error reason. @todo any?
-
-
-
-
Wait for a response body.
-
This function can be used when a synchronous handling of
-responses is desired. It will only return when it has
-finished fetching the entire response body.
-
The timeout value is per message. The actual function call
-can last much longer for large bodies.
-
@todo I think we want to distinguish a stream error, a general error,
-@todo a DOWN and a timeout error
-
@todo guide might be a little incorrect about await/await_body
-
-
-
flush(ConnPid) → ok
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-
Flush all messages from the Gun connection process from the mailbox.
-
-
-
flush(StreamRef) → ok
-
-
-StreamRef = reference()
-
-
-
-Stream identifier.
-
-
-
-
Flush all messages related to the given stream.
-
-
-
cancel(ConnPid, StreamRef) → ok
-
-
-ConnPid = pid()
-
-
-
-The pid of the Gun connection process.
-
-
-
-StreamRef = reference()
-
-
-
-Identifier of the stream to cancel.
-
-
-
-
Cancel the given stream.
-
HTTP/1.1 streams can’t be cancelled. Gun will simply silence
-the stream and stop relaying messages.
-
@todo Depending on the length
-@todo of a response Gun may also attempt to reconnect rather than
-@todo receive the entire response body.
-
HTTP/2 streams can however be cancelled at any time.
gun - Erlang HTTP client with support for HTTP/1.1, HTTP/2 and Websocket.
+
gun - HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP
+
+
+
+
Description
+
+
Gun is an HTTP client for Erlang/OTP with support for the
+HTTP/1.1, HTTP/2 and Websocket protocols.
+
Gun aims to provide an easy to use, asynchronous and
+always-connected client. It maintains a permanent connection
+to the server and reconnects automatically when necessary.
The gun application uses the Erlang applications ranch
-for abstracting TCP and TLS over a common interface, and
-the ssl application for TLS support, required for HTTPS
-and secure HTTP/2 support. In addition, Gun requires the crypto
-application (a dependency of ssl) for Websocket.
-
These dependencies must be started for the gun
-application to work. In an embedded environment
-this means that they need to be started with the
-application:start/{1,2} function before the gun
-application is started.
+
+
+
+cowlib(7) - Support library for manipulating Web protocols
+
+
+
+
+ssl - Secure communication over sockets
+
+
+
+
All these applications must be started before the gun
+application. To start Gun and all dependencies at once:
This message informs the owner process that the connection
+was lost. Depending on the retry and retry_timeout
+options Gun may automatically attempt to reconnect.
+
When the connection goes back up, Gun will not attempt to retry
+requests. It will also not upgrade to Websocket automatically
+if that was the protocol in use when the connection was lost.
+
+
+
+
Elements
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Protocol
+
+
+
+The protocol that was selected for this connection
+or upgraded to during the course of the connection.
+
+
+
+Reason
+
+
+
+The reason for the loss of the connection.
+
+
It is present for debugging purposes only. You should not
+rely on this value to perform operations programmatically.
+
+
+KilledStreams
+
+
+
+List of streams that have been brutally terminated.
+
+
They are active streams that did not complete before the closing
+of the connection. Whether they can be retried safely depends
+on the protocol used and the idempotence property of the requests.
+
+
+UnprocessedStreams
+
+
+
+List of streams that have not been processed by the server.
+
+
They are streams that the server did not start processing yet.
+They may be retried safely depending on whether related streams
+were killed.
These messages inform the relevant process that an error
+occurred. A reference is given when the error pertains
+to a specific stream. Connection-wide errors do not
+imply that the connection is no longer usable, they are
+used for all errors that are not specific to a stream.
+
+
+
+
Elements
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+StreamRef
+
+
+
+Identifier of the stream that resulted in an error.
+
+
+
+Reason
+
+
+
+The reason for the error.
+
+
It is present for debugging purposes only. You should not
+rely on this value to perform operations programmatically.
This message informs the relevant process that the server
+sent an informational response to the original request.
+
Informational responses are only intermediate responses
+and provide no guarantees as to what the final response
+will be. An informational response always precedes the
+response to the original request.
+
+
+
+
Elements
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+StreamRef
+
+
+
+Identifier of the stream for the original request.
+
This message informs the owner process that the connection or
+reconnection completed.
+
Gun will now start processing the messages it received while
+waiting for the connection to be up. If this is a reconnection,
+then this may not be desirable for all requests. Those requests
+should be cancelled when the connection goes down, and any
+subsequent messages ignored.
+
+
+
+
Elements
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+Protocol
+
+
+
+The protocol selected for this connection. It can be used
+to determine the capabilities of the server.
+
This message informs the relevant process that the server
+accepted to upgrade to one or more protocols given in the
+original request.
+
The exact semantics of this message depend on the original
+protocol. HTTP/1.1 upgrades apply to the entire connection.
+HTTP/2 uses a different mechanism which allows switching
+specific streams to a different protocol.
+
Gun currently only supports upgrading HTTP/1.1 connections
+to the Websocket protocol.
+
+
+
+
Elements
+
+
+
+ConnPid
+
+
+
+The pid of the Gun connection process.
+
+
+
+StreamRef
+
+
+
+Identifier of the stream that resulted in an upgrade.
+