Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
It is completely removed for connection processes, because
assuming Cowboy is written properly this should bring us
nothing anymore in 2.0.
It is reworked for request processes, there we want to
always propagate the stacktrace (including for exits)
because we will print a report to help with debugging
and proc_lib doesn't propagate it for exits.
At the same time the initial callback for connection
and request processes has been changed to connection_process
and request_process, which should help with identifying
processes when inspecting.
|
|
When the request process exits with a {request_error, Reason, Human}
exit reason, Cowboy will return a 400 status code instead of 500.
Cowboy may also return a more specific status code depending on
the error. Currently it may also return 408 or 413.
This should prove to be more solid that looking inside the stack
trace.
|
|
|
|
|
|
The header never reaches this point.
|
|
|
|
This will result in no data being sent. It's simply easier to
do this than to have to handle 0 size cases in user code.
|
|
|
|
|
|
I have decided not to include a manual page for
cowboy_stream_h at this point because it clashes
with the cowboy_stream manual page. This decision
will be revisited in the future.
|
|
|
|
|