Age | Commit message (Collapse) | Author |
|
This fixes curl when fetching resources that use push.
|
|
|
|
Depend on Cowlib master for the moment.
|
|
|
|
|
|
This is a first step toward properly supporting request trailers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Using the current draft:
https://tools.ietf.org/html/draft-ietf-httpbis-h2-websockets-01
|
|
Currently cowboy assumes that idle_timeout or request_timeout is
a number and always starts timers. Similar situation takes place
in case of preface_timeout for http2. This commit adds case for
handling infinity as a timeout, allowing to not start mentioned
timers.
|
|
|
|
|
|
|
|
|
|
Send errors produce annoying logs and we notice the connection
is gone later on anyway.
|
|
|
|
It's safer than allow it with the wrong behavior.
|
|
In some cases there could be a body sent as a response to
a HEAD request when using HTTP/2. This has been corrected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cowboy takes a few shortcuts to avoid wasting resources when
there is a protocol error. The RFC wants us to send a different
error depending on the state of the stream at the time of the
error, and for us to maintain the connection in cases where we
would have to spend valuable resources to decode headers. In
all these cases Cowboy will simply close the connection with
an appropriate error.
|
|
|
|
This depends on changes in Cowlib that are only available on
master.
|
|
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.
|
|
|
|
User code can now send as many 1xx responses as necessary.
|
|
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.
|
|
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.
|
|
Also corrects the lack of error response when HTTP/1.1 is used.
|
|
|
|
|
|
The documentation was correct, the code was not.
This should make it easier to implement new protocols. Note that
for HTTP/2 we will need to add some form of counting later on to
check for malformed requests, but we can do simpler and just
reduce from the expected length and then check if that's 0 when
IsFin=fin.
|
|
|
|
|
|
This should work very similar to normal supervisors,
in particular during the shutdown sequence when the
connection process goes down or switches to Websocket.
Processes that need to enforce the shutdown timeout
will be required to trap exits, just like in a supervisor.
In a vanilla Cowboy, this only matters at connection
shutdown, as Cowboy will otherwise wait for the request
process to be down before stopping the stream.
Tests are currently missing.
|
|
Cowboy was encoding the headers then decoding them when initializing
the request. The problem is that the encoding and decoding contexts
are not the same. Now, Cowboy will directly use the headers it
received in the push command for the new request. This is also
more efficient.
I am surprised it worked at all considering the issue.
|
|
This and the issues in the last two commits were reported
by leo2007 on IRC.
|
|
The previous code was incorrectly substracting the maximum
frame size we could send when the data we were actually sending
was much lower.
|
|
|