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.
To avoid intermittent test failures. We only want to make
sure the function eventually returns so we don't need to
use timeouts in the test itself, or check exactly what was
read.
This should limit the amount of memory that Cowboy is using
when a handler is sending data much faster than the network.
The new max_stream_buffer_size is a soft limit and only has
an effect when the cowboy_stream_h handler is used.
It is now possible to stream one or more sendfile tuples.
A simple example of what can now be done would be for
example to build a tar file on the fly using the sendfile
syscall for sending the files, or to support Range requests
with more than one range with the sendfile syscall.
When using cowboy_compress_h unfortunately we have to read
the file in order to send it. More options will be added
at a later time to make sure users don't read too much
into memory. This is a new feature however so existing
code is not affected.
Also rework cowboy_http's data sending to be flatter.
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.
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).
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.
