Age | Commit message (Collapse) | Author |
|
|
|
Bad chunk sizes used to be accepted and could result in
a badly parsed body or a timeout. They are now properly
rejected.
Chunk extensions now have a hard limit of 129 characters.
I haven't heard of anyone using them and Cowboy does not
provide an interface for them, but we can always increase
or make configurable if it ever becomes necessary (but
I honestly doubt it).
Also a test from the old http suite could be removed. Yay!
|
|
It's worth noting that transfer-encoding now takes precedence
over content-length as recommended by the RFC, so that when
both headers are sent we only care about transfer-encoding
and explicitly remove content-length from the headers.
|
|
|
|
|
|
Also fixes the handling of the max_headers option for HTTP/1.1.
It is now a strict limit and not dependent on whether data is
already in the buffer.
|
|
This depends on changes in Cowlib that are only available on
master.
|
|
This only happens if the switch takes too long, and should not
happen unless a spawned process refuses to shut down immediately.
|
|
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.
|
|
|
|
|
|
To obtain the local socket ip/port and the client TLS
certificate, respectively.
|
|
|
|
I broke this when fixing stream handlers earlier.
|
|
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 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.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
Introduces the new stream_handler_SUITE test suite. More cases
will be added later on.
|
|
|
|
|
|
This is a more or less temporary solution to an existing problem.
In the future we will need to enforce a shutdown timeout for
these processes.
|
|
This fixes the connection being dropped because of request_timeout
despite there being some active streams.
|
|
|
|
To accomplish this the code for sending the 101 response was
moved to the cowboy_http2 module.
|
|
This callback is called when an error occurs before the request
(including headers, excluding body) was fully received. The
init/3 callback will not be called. The callback receives the
partial Req object (possibly empty), the reason for the error
and the response command that the server will send. It allows
you to be aware of the error and possibly modify the response
before it is sent.
|
|
Before this commit we had an issue where configuring a
Websocket connection was simply not possible without
doing magic, adding callbacks or extra return values.
The init/2 function only allowed setting hibernate
and timeout options.
After this commit, when switching to a different
type of handler you can either return
{module, Req, State}
or
{module, Req, State, Opts}
where Opts is any value (as far as the sub protocol
interface is concerned) and is ultimately checked
by the custom handlers.
A large protocol like Websocket would accept only
a map there, with many different options, while a
small interface like loop handlers would allow
passing hibernate and nothing else.
For Websocket, hibernate must be set from the
websocket_init/1 callback, because init/2 executes
in a separate process.
Sub protocols now have two callbacks: one with the
Opts value, one without.
The loop handler code was largely reworked and
simplified. It does not need to manage a timeout
or read from the socket anymore, it's the job of
the protocol code. A lot of unnecessary stuff was
therefore removed.
Websocket compression must now be enabled from
the handler options instead of per listener. This
means that a project can have two separate Websocket
handlers with different options. Compression is
still disabled by default, and the idle_timeout
value was changed from inifnity to 60000 (60 seconds),
as that's safer and is also a good value for mobile
devices.
|
|
One had the todo text fixed, another had the task to do done.
|
|
|
|
The {data, IsFin, Data} uses IsFin to indicate whether this
is the last chunk, while chunked transfer-encoding uses the
length of Data, and ends when it is 0. We must therefore not
send chunks with empty data.
|
|
The stream handlers can be specified using the protocol
option 'stream_handlers'. It defaults to [cowboy_stream_h].
The cowboy_stream_h module currently does not forward the
calls to further stream handlers. It feels like an edge
case; usually we'd want to put our own handlers between
the protocol code and the request process. I am therefore
going to focus on other things for now.
The various types and specifications for stream handlers
have been updated and the cowboy_stream module can now
be safely used as a behavior. The interface might change
a little more, though.
This commit does not include tests or documentation.
They will follow separately.
|
|
This commit changes Cowboy to follow RFC6585.
|
|
|
|
|
|
|
|
Removes some duplicate code from cowboy_http.
|
|
|
|
|
|
|
|
|
|
This is a large commit. The cowboy_req interface has largely
changed, and will change a little more. It's possible that
some examples or tests have not been converted to the new
interface yet. The documentation has not yet been updated.
All of this will be fixed in smaller subsequent commits.
Gotta start somewhere...
|
|
|
|
The stream handler is responsible for sending errors.
The protocol should only send errors when no responses
were sent (this might not work yet).
|
|
|
|
The same edge cases that fail with other handshake methods
also fail here (mostly bad preface/timeouts stuff). In
addition, the HTTP2-Settings header contents are currently
not checked and so the related edge case tests also fail.
|
|
Currently only testing handshake.
Tests that pass currently involve no request/response.
ALPN and prior knowledge support have some edge cases left to fix.
HTTP/1.1 Upgrade has not been implemented yet.
|