| 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.
|
|
We are about one week before the actual release.
|
|
|
|
|
|
Has a timer:sleep/1 though because there is currently no way
to wait for the TLS handshake to complete.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We instead of two new modules, gun_tcp and gun_tls.
They only have 6 functions so far, much less than
what Ranch provided before.
Also renames ssl to tls where applicable. It's still
possible to use the ssl transport option but it's now
undocumented.
|
|
|
|
|
|
|
|
|
|
I just replaced "SPDY" with "HTTP/2" in the documentation.
I suspect that's all that's needed, but if there's something
off we can fix it later.
|
|
This functionality can be used to implement custom protocols
on top of Websocket, but may also be used to decode frame
contents on the fly if necessary.
The default_protocol option defines what module should be
used when no protocol was selected.
The protocols option is a list of key/value pairs used to
select the handler depending on the protocol that the server
accepted.
The feature is currently experimental.
|
|
Content handlers are a chain of modules implementing callbacks
that receive the body of responses and may modify it (for example
for decompressing the content) or act upon it (like sending a
message to the owner process.
The gun_sse content handler module can be used to translate
text/event-stream events on the fly and deliver them to the
owner process as a {gun_sse...} message.
This feature is currently not documented and is only tested
against a public server. It requires an up to date Cowlib.
|
|
|
