Age | Commit message (Collapse) | Author |
|
It was mistakenly discarded.
|
|
|
|
|
|
|
|
Also add OTP-20.1.4 to CI.
|
|
|
|
|
|
This can happen normally when Cowboy is restarted, for example.
Instead of failing requests when that happens, we degrade
gracefully and do a little more work to provide the current
date header.
|
|
Also {switch_handler, Module, Opts}.
Allows switching to a different handler type. This is
particularly useful for processing most of the request
with cowboy_rest and then streaming the response body
using cowboy_loop.
|
|
Unfortunately compression will be disabled for 20.1, 20.1.1
and 20.1.2. In additiona I do not recommend 20.1.3 due to
issues inflating some specific sizes.
|
|
Sending data of size 0 with the fin flag set resulted in nothing
being sent to the client and still considering the response to
be finished for HTTP/1.1.
For both HTTP/1.1 and HTTP/2, the final chunk of body that is
sent automatically by Cowboy at the end of a response that the
user did not properly terminate was not passing through stream
handlers. This resulted in issues like compression being incorrect.
Some tests still fail under 20.1.3. They are due to recent zlib
changes and should be fixed in a future patch release. Unfortunately
it does not seem to be any 20.1 version that is safe to use for
Cowboy, although some will work better than others.
|
|
|
|
|
|
|
|
|
|
Bad requests correctly return 400, not 500.
|
|
|
|
The 100 continue response will only be sent if the client
has not sent the body yet (at all), if the connection is
HTTP/1.1 or above and if the user has not sent it yet.
The 100 continue response is sent when the user calls
read_body and it is cowboy_stream_h's responsibility
to send it. This means projects that don't use the
cowboy_stream_h stream handler will need to handle the
expect header themselves (but that's okay because they
might have different considerations than normal Cowboy).
|
|
User code can now send as many 1xx responses as necessary.
|
|
Another experimental stream handler. It enables tracing for
the connection process and any children processes based on
the matching of the request. It can be used to do ad-hoc
tracing by sending a specific header, path, method or other.
It is meant to be used both for tests and production. Some
configuration scenarios are NOT safe for production, beware.
It's important to understand that, at this time, tracing
is enabled on the scale of the entire connection including
any future request processes. Keep this in mind when trying
to use it in production. The only way to stop tracing is
by having the callback function exit (by calling exit/1
explicitly). This can be done after a certain number of
events for example. Tracing can generate a lot of events,
so it's a good idea to stop after a small number of events
(between 1000 and 10000 should be good) and to avoid tracing
the whole world.
Documentation will follow at a later time.
|
|
To obtain the local socket ip/port and the client TLS
certificate, respectively.
|
|
|
|
When the user code was sending a response fully without reading
the request body, the connection could get closed when receiving
DATA frames for that body. We now ask the client to stop sending
data via a NO_ERROR RST_STREAM, and linger any stream that has
been reset so that we can skip any pending frames from that
stream.
This fixes a number of intermittent failures in req_SUITE, which
now passes reliably.
In addition a small number of rfc7540_SUITE test cases have been
corrected as they were incorrect.
|
|
|
|
|
|
|
|
I broke this when fixing stream handlers earlier.
|
|
|
|
Also fix a test group to use h2 instead of HTTP/1.1.
|
|
When we have to send a response before terminating a stream,
we call info. The state returned by this info call was
discarded when we called terminate after that. This commit
fixes it.
There are no tests for this, however the new metrics test
in the next commit requires the correct behavior so this
is ultimately covered.
|
|
|
|
It collects metrics and passes them to a configurable callback
once the stream terminates. It will be documented in a future
release. More tests incoming.
|
|
It is possible in some cases to move on to the next request
without waiting, but that can be done as an optimization
later on if necessary.
|
|
|
|
|
|
|
|
|
|
Hello 2.0.0!
|
|
|
|
|
|
|
|
I have amended a lot of changes from the original commit
to make it behave as expected, including returning a 400
error. LH
|
|
|
|
|
|
|
|
|
|
|
|
Also corrects the lack of error response when HTTP/1.1 is used.
|
|
|
|
|