| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This is meant to be used with clients such as Gun to simplify
proxying and similar operations. The set-cookie header must
not be set this way so there is still some extra processing
to be done to fully translate a Gun response into a Cowboy
response.
|
|
Not just on 405 responses or OPTIONS requests.
|
|
|
|
To avoid intermittent errors that are more likely as more
tests are calling cowboy:stop_listener.
|
|
Over cleartext TCP the `protocols` option lists the enabled
protocols. The default is to allow both HTTP/1.1 and HTTP/2.
Over TLS the default protocol to use when ALPN is not used
can now be configured via the `alpn_default_protocol` option.
Performing an HTTP/1.1 upgrade to HTTP/2 over TLS is now
rejected with an error as connecting to HTTP/2 over TLS
requires the use of ALPN (or that HTTP/2 be the default
when connecting over TLS).
|
|
Before this change invalid return values would be detected
via unhelpful error messages such as [1] and the closing
of the connection.
[1] Bad value on output port 'tcp_inet'
|
|
Because the exit reason doesn't include the stacktrace they
were ignored. Now they are properly handled. The error message
was changed slightly to accomodate.
|
|
When enabled the connection process will automatically hibernate.
Because hibernation triggers GC, this can be used as a way to
keep memory usage lower, at the cost of performance.
|
|
|
|
When 3 or more cookies were sent the extra cookies were not
found because the binary:split on ";" stopped at the first
occurrence.
|
|
The problem was that when a request immediately following another
request with a large enough body, the data for the new request
(including headers) would be buffered waiting for more data,
instead of being processed immediately. If no more data came
in on the socket the request_timeout would eventually trigger.
Now the buffer is processed immediately.
|
|
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
|
|
|
|
|
|
When the server has a non-default value configured and the client
doesn't send one the extension negotiation should fail.
|
|
Before this commit frames could "cheat" by compressing data
below the limit which would get expanded above the limit.
Now Cowboy will stop decompressing data when the limit is
reached.
|
|
|
|
This can be used to limit the maximum frame size before
some authentication or other validation is completed.
|
|
|
|
Following the same strategy as Websocket described in
commit cbed21c383e4cebb7df5a0a8b81f18c1738bef3e
Gains are comparable as far as Websocket over HTTP/2
is concerned.
|
|
`perf` has shown that Cowboy spends a lot of time
cancelling and starting this timer. Instead of resetting
for every data received, we now only reset a field in the
state.
Before it was working like this:
- start idle timeout timer
- on trigger, close the connection
- on data, cancel and start again
Now it's working like this:
- start idle timeout timer for a tenth of its duration, with tick number = 0
- on trigger, if tick number != 10
- start the timer again, again for a tenth of its duration
- increment tick number
- on trigger, if tick number = 10
- close the connection
- on data, set tick number to 0
|
|
It benchmarks binary, ascii, mixed and japanese data
using Websocket and Websocket over HTTP/2.
HTTP/2 options get set to ensure that performance is
better than the default HTTP/2 options.
It switches to Gun and Ranch branches that include
fixes that are required for tests to complete successfully.
|
|
|
|
This includes Websocket over HTTP/3.
Since quicer, which provides the QUIC implementation,
is a NIF, Cowboy cannot depend directly on it. In order
to enable QUIC and HTTP/3, users have to set the
COWBOY_QUICER environment variable:
export COWBOY_QUICER=1
In order to run the test suites, the same must be done
for Gun:
export GUN_QUICER=1
HTTP/3 support is currently not available on Windows
due to compilation issues of quicer which have yet to
be looked at or resolved.
HTTP/3 support is also unavailable on the upcoming
OTP-27 due to compilation errors in quicer dependencies.
Once resolved HTTP/3 should work on OTP-27.
Because of how QUIC currently works, it's possible
that streams that get reset after sending a response
do not receive that response. The test suite was
modified to accomodate for that. A future extension
to QUIC will allow us to gracefully reset streams.
This also updates Erlang.mk.
|
|
|
|
|
|
Original fix by Ali Farhadi <[email protected]>.
|
|
To avoid having the connection get closed due to us taking
too long on unreliable environments like GitHub Actions.
|
|
This is caused by the timeout being 1s after the period.
When the CI environment is overloaded, sometimes the
timeout will trigger. We retry, knowing that the
timetrap will catch us if we retry too much.
|
|
GitHub Actions runners are not as good as self-hosted BuildKite
so some adjustments need to be made to timeouts and such.
|
|
This allows conditionally generating an etag.
|
|
|
|
|
|
LH: The tests received a lot of fixes and tweaking.
I also reworded the error message to be more concise.
|
|
Added many tests to ensure the right timeout is picked in
the appropriate situation. Should there be any issues
remaining we can add more tests.
|
|
Also crash if trying to push after a reply was sent.
|
|
|
|
It is now tested both via cowboy_req:read_body and
via cowboy_req:cast.
Removes a bad example from the guide of body reading
with period of infinity, which does not work.
|
|
While we are identified as a supervisor in the tree,
we no longer manage children processes at that point,
so do not need to trap exit signals. Users can still
enable trap_exit if they prefer to.
|
|
We must add it even if we don't end up compressing because
it indicates that we might. This indication doesn't mean
that the user agent's accept-encoding values will ever
result in content encoding being applied.
|
|
The previous behavior was to accept them and drop the
content-length header as per the RFC recommendation.
But since this behavior is not normal it is safer to
just reject such requests than risk security issues.
|
|
In the cowboy_compress_h stream handler.
Otherwise this could cause issues with caching, with the
etag being the same for compressed/uncompressed content.
Users that wish to send etags AND compress will have to
do it manually for the time being.
|
|
|
|
The read buffer was changed into an iovec to avoid doing
too many binary concatenations and allocations.
Decompression happens transparently: when decoding gzip,
the content-encoding header is removed (we only decode
when "gzip" is the only encoding so nothing remains).
We always add a content_decoded key to the Req object.
This key contains a list of codings that were decoded,
in the reverse order in which they were. Currently it
can only be empty or contain <<"gzip">> but future
improvements or user handlers may see it contain more
values.
The option to disable decompression was renamed to
decompress_enabled and defaults to true.
It is no longer possible to enable/disable decompression
in the middle of reading the body: this ensures that the
data we pass forward is always valid.
Various smaller improvements were made to the code,
tests and manual pages.
|
|
|
|
LH: Simplified the test a little.
|
|
A new option reset_idle_timeout_on_send has been added.
When set to 'true', the idle timeout is reset not only
when data is received, but also when data is sent.
This allows sending large responses without having to
worry about timeouts triggering.
The default is currently unchanged but might change in
a future release.
LH: Greatly reworked the implementation so that the
timeout gets reset on almost all socket writes.
This essentially completely supersets the original
work. Tests are mostly the same although I
refactored a bit to avoid test code duplication.
This commit also changes HTTP/2 behavior a little when
data is received: Cowboy will not attempt to update the
window before running stream handler commands to avoid
sending WINDOW_UPDATE frames twice. Now it has some
small heuristic to ensure they can only be sent once
at most.
|
