Age | Commit message (Collapse) | Author |
|
Also add a test for CONNECT to TLS via 2 TLS proxies.
|
|
|
|
Match inside the clause instead. This should make clearer
the occasional failure.
|
|
|
|
|
|
To attempt to fix a timetrap_timeout issue occuring sometimes.
I have little confidence about this fixing anything but it will
not hurt either.
|
|
Instead of timeouts, favor receiving events from the event
handler gun_test_event_h. Remove most other timeouts in particular
receive timeouts in favor of a Common Test timetrap timeout global
to this test suite of 30 seconds.
|
|
|
|
Turns out we can't rely on IPv4 being available if we set
the socket in IPv6 mode. Instead the origin is modified to
either setup IPv4 or IPv6 depending on the test's needs.
|
|
|
|
It seems that the retry behavior changed recently. It would
be better to retrieve the exact values and calculate how much
time we want to wait but that will do for now.
|
|
|
|
|
|
|
|
|
|
|
|
And make sure all HTTP/2 connection_error(s) result in a
gun_down message containing the error. In the preface case
we do not send a gun_error message (because there's no stream
open yet) and gun_down was always saying normal.
Also make sure the human readable reason is included in the
gun_error message, if any.
|
|
|
|
|
|
|
|
The reply_to option is also propagated when we switch protocols.
|
|
While at it the gun:info/1 function has been fixed to work
even when we are in the not_connected state, and the owner
is now also returned.
|
|
The auto-ping will at regular interval send a ping frame.
The silence_pings option defaults to true. It can be set
to false when the user needs to receive ping/pong frames.
|
|
|
|
Gun can now be used to send or receive arbitrary data in the
following scenarios:
* Directly after connecting to a server (this is not terribly
useful but it works nevertheless due to the Gun architecture)
* After connecting through one or more Socks and/or HTTP proxies.
This allows using Gun's proxy capabilities to access servers
located beyond firewalls.
* After performing an HTTP/1.1 Upgrade. This allows using Gun
to implement custom protocols that require upgrading from
an HTTP/1.1 connection.
As there is still no support for HTTP/2 CONNECT for the time
being, there are no relevant streams attached to those use
cases and therefore the raw protocol currently expects users
to use 'undefined' as the StreamRef value. This is not a
final decision and will most likely produce a Dialyzer
warning at this time.
|
|
|
|
When Windows can't connect it retries 2 more times with
500ms wait in-between by default.
|
|
I'm not exactly sure why it works but it seems to be solid now.
I think the issue is around timeouts in the test and handler
being too close to one another.
|
|
It is better covered by the shutdown_SUITE.
|
|
Also correct various Socks related types. This commit also
adds a new gun:protocols/0 type as a simpler way of describing
preferred protocols. The protocol/opts tuple is also documented.
This commit also fixes an issue with the default value for the
preferred protocols when using CONNECT over TLS. It was
mistakenly not enabling http2 by default.
|
|
Also fix the multiple TLS proxies tests from the previous commit.
|
|
We now properly support TCP across two TLS proxies, and
TLS across two TCP/TLS proxies.
|
|
This commit also reworks the switch_protocol command.
The `P | {P, Opts}` type is used here as well. This
allows us to remove the code specific to Websocket.
In addition a few new protocol functions allow us
to declare what's the name of the options key for
the protocol and what the capabilities are with
regard to keepalive.
|
|
Also consolidate the ALPN code in the tls_handshake state
rather than doing it in CONNECT/Socks separately.
Also improves the origin tests by sending a message once
the handshake is completed instead of having timeouts.
|
|
|
|
|
|
|
|
|
|
Gun was very inefficient at receiving HTTP/2 bodies. Switching
to ensure_window and increasing the default window sizes brings
the response body reading performance at least on par with the
one for HTTP/1.1.
This has a small negative impact on message flow control because
we stop updating the window later than we did before, increasing
the number of extra messages we may send. The exact amount depends
on configuration and the exact moment flow control kicks in.
|
|
|
|
The graceful shutdown is implemented through a new 'closing'
state. This state is entered under different circumstances
depending on the protocol.
The gun:shutdown/1 function is now implemented and documented.
It allows shutting down the connection gracefully regardless
of the current state of the connection and for all protocols.
The behavior is entirely dependent on the protocol.
For HTTP/1.1 the connection stays up only until after the
current stream is complete; other streams are immediately
canceled.
For HTTP/2 a GOAWAY frame is sent and existing streams
continue to be processed. The connection is closed after
all streams are processed and the server's GOAWAY frame
is received.
For Websocket a close frame is sent. The connection is
closed when receiving the server's close frame.
In all cases the closing_timeout option defines how long
we wait, as a maximum, before closing the connection after
the graceful shutdown was started.
The graceful shutdown is also initiated when the owner
process goes away; when sending an HTTP/1.1 request
with the connection: close header; when receiving an
HTTP/1.1 response with the connection: close header;
when receiving an HTTP/1.0 response without a connection
header; when the server sends a GOAWAY HTTP/2 frame;
or when we send or receive a Websocket close frame.
Along with these changes, the gun:ws_send/2 function
now accepts a list of frames as argument. Those frames
may include a close frame that initiates the graceful
shutdown.
|
|
|
|
|
|
On Windows the timings can be flaky. It's better to retry a
few times rather than fail immediately.
|
|
Should improve test success rates on Windows.
|
|
|
|
Flow control is disabled by default. The initial flow value
must be set to enable it (either for the entire connection
or on a per-request basis). Flow applies to all HTTP streams
as well as Websocket. HTTP/2 pushed streams receive the same
value as their originating stream.
|
|
|
|
|
|
|