| Age | Commit message (Collapse) | Author |
|---|
|
The approach taken here is very similar to what browsers are
doing. A separate pool is created for each host/port/scope.
The authority (host header) is used to determine which pool
will execute requests. A connection process is semi-randomly
chosen, from the connections that have capacity. Maximum
capacity is determined by the protocol (the HTTP/2 setting
set by the server is used, for example). Multiple processes
can process requests/responses on the same connection
concurrently. There is no need to "give back" the response
to the pool, the number of ongoing streams is maintained via
an event handler.
The implementation is currently not strict, there may be
more attempts to create requests than there is capacity.
I'm not sure if it should be made strict or if Gun should
just wait before sending requests (it only matters in the
HTTP/2 case at the moment).
When there is no connection with capacity available in the
pool (because they have too many streams, or are reconnecting,
or any other reason), checking out fails. There is no timeout
to wait for a connection to be available. On the other hand
the checkout_retry option allows setting multiple timeouts
to retry checking out a connection. Each retry attempt's
wait time can have a different value.
The initial implementation of this work was sponsored by
Kobil and made at the suggestion of Ilya Khaprov.
|
|
|
|
If a request/headers/connect/ws_upgrade is created when a connection is in state
'closing', such as after receiving an HTTP/2 GOAWAY frame or an HTTP/1.1
"Connection: close" header, an error message is sent back to the caller
immediately, if reconnect is off (that is if the option retry is set to 0).
This allows an application to retry the request on another connection without
waiting for all streams on the current connection to complete.
|
|
|
|
HTTP/1.1 Upgrade to HTTP/2 will not be implemented. There are
discussions for this functionality to be removed from the
HTTP/2 spec.
HTTP/1.1 Upgrade to TLS will most likely not be implemented.
|
|
While the stream has not ended, the response has.
|
|
|
|
The cookie_ignore_informational has been moved to http_opts and
http2_opts.
Also fix an issue when using 'protocols' in gun:open.
When connecting via TLS the protocol's options were
discarded.
|
|
There are still small issues left to fix. In particular the
set_cookie command should be replaced with doing the same
in the protocol itself so that the scheme is correct. So
CookieStore must be propagated to all callbacks.
|
|
|
|
|
|
The test suite is 216 tests with a tunnel created via two
proxies leading to one origin server. The tests are for
example socks5_h2_https where socks5 identifies the first
SOCKS5 proxy, h2 the second HTTP/2 CONNECT proxy and https
the secure HTTP/1.1 origin server.
The test not only sets up the tunnel and does a request
(or sends/receives data in the case of raw origin servers)
but also confirms that the stream_info and info data is
correct.
|
|
|
|
|
|
|
|
Also fixes all the tests. Lots of work remain around protocols
(how best to pass the base stream_ref to them? maybe the current
solution, maybe a new argument to Protocol:init) and strengthen
the concept of stream_ref, at least with its own type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also rework the different handle_head scenarios in separate
functions.
|
|
|
|
The reply_to option is also propagated when we switch protocols.
|
|
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.
|
|
|
|
The version is still kept in the state even if it's an option
because it's useful to have there and it's just a tiny atom.
|
|
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.
|
|
We now properly support TCP across two TLS proxies, and
TLS across two TCP/TLS proxies.
|
|
When doing a CONNECT from http to http or from socks to socks
we may want to use different configuration options. Switching
the protocol explicitly helps us achieve that. It will also
signal through events that a protocol switch occurred.
|
|
|
|
|
|
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.
|
|
|
|
There's now an initial_tls_handshake state for the initial
connection with handshake, and tls_handshake state for any
subsequent TLS handshakes.
The Socks5 code will be able to reuse this tls_handshake
state to perform its own transport switches.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
And ensure that Websocket triggers all the request/response
events.
|
|
|
|
Thought it needed cow_http2_machine changes but everything
was available. For HTTP/1.1 it is triggered when receiving
data while expecting headers. For HTTP/2 it is triggered
after we have received a HEADERS frame for streams in idle
state.
|
|
This covers many scenarios but more need to be added.
|
|
|
