This new protocol option is a fun.
It expects 3 args: the Status code used in the reply (this is the
cowboy_http:status() type, it can be an integer or a binary), the
headers that will be sent in the reply, and the Req. It should
only return a possibly modified Req. This can be used for many
things like error logging or custom error pages.
If a reply is sent inside the hook, then Cowboy will discard the
reply initially sent. Extra caution must be used in the handlers
making use of inline chunked replies as they will throw an error.
This fun cannot be used as a filter, you can either observe the
reply sent or discard it to send a different one instead.
The hook will not be called for replies sent from inside the hook.
Use a proper HTTP client to run all tests. This client is currently
undocumented and should not be used.
Includes a few fixes:
* Fix a bug in the max_keepalive test
* Fix a bug with max_keepalive handling
* Fix a bug in stream_body/1 where data was lost under some conditions
The tests now run quite faster than before.
All the tests now run twice: once for TCP, once for SSL.
Introduces 3 low level functions and updates the existing higher
levels functions. The new primitives are has_body/1, body_length/1
and stream_body/1. In addition to that, a helper function
init_stream/4 has been added.
Streaming a body implies to decode the Transfer-Encoding and
Content-Encoding used for the body. By default, Cowboy will try
to figure out what was used and decode them properly. You can
override this if you want to disable this behavior or simply
support more encodings by calling the init_stream/4 function
before you start streaming the body.
This new protocol option is a fun.
It expects a single arg, the Req, and should only return a possibly
modified Req. This can be used for many things like URL rewriting,
access logging or listener-wide authentication.
If a reply is sent inside the hook, then Cowboy will consider the
request handled and will move on to the next one.
The return value from the generate_etag/2 callback is expected to be a
binary tagged with either weak or strong. This binary is quoted, and
may be prefixed with W/ before it is set as the value of the ETag header
in the response.
For backwards compatibility with older handlers where the return value
was expected to be a quoted binary a function has been added to parse any
return values that are untagged binaries. All untagged binaries are expected
to be a valid value for the ETag header.
If requests go through a proxy, they will have the original uri in the
request, i.e. : GET http://proxy.server.uri/some/query/string HTTP 1.1 ...
That was problematic -- cowboy_http_protocol:request didn't know what to
to with the result of decode_packet applied to this, which would be something
like:
``` erlang
{http_request,'GET',{absoluteURI,http,<<"proxy.server.uri">>,
undefined,<<"/some/query/string">>},{1,1}}
```
So, I just ignore the host, grab the path and pass into
``` erlang
cowboy_http_protocol:request({http_request, Method, {abs_path, Path},
Version}, State)
```
Seems to do the trick without much effort.
It was replying back the correct error, but with a crash message in
the console. This patch prevents it from crashing.
Fixes issue #94 reported by oribrost.
As with everything experimental, it probably has a lot of bugs and
may not even work.
Like Websocket, REST must be upgraded from a standard resource through
the init/3 function.
A key difference between Webmachine and Cowboy's REST protocol handler
is that in Cowboy the resource has direct access to the request object.
This makes a small change in a few places where you were expected to
return headers or body in Webmachine and are now expected to set them
directly yourself if needed (options/2, for example).
Another difference is that the functions rest_init/2 will always be
called when starting to process a request. Similarly, rest_terminate/2
will be called when the process completes successfully.
The Cowboy REST support also includes automatic language selection,
thanks to the languages_provided/2 callback.
Finally, Cowboy REST expects full URIs to be given at all times, and
will not try to reconstruct URIs from fragments.
Note that REST requests cannot be chained (keepalive) at this time.
This is a design issue in cowboy_http_protocol that will be fixed soon.
Check out the source for more details. It has been designed to be very
easy to read and understand so if you don't understand something,
it's probably a bug. Thanks in advance for all the great bug reports,
pull requests and comments you'll forward my way!
These functions allow to set response headers and body in advance,
before calling any of the reply functions.
Also add has_resp_header/2 and has_resp_body/1 to check if the given
response headers have already been set.
Allows to limit the size of request and header lines, thus preventing
Cowboy from infinitely reading from the socket and never finding an
end of line.
Defaults to 4096 bytes.
Now init/3 can return one of the following values to enable loops:
- {loop, Req, State}
- {loop, Req, State, hibernate}
- {loop, Req, State, Timeout}
- {loop, Req, State, Timeout, hibernate}
Returning one of these tuples will activate looping in the HTTP handler.
When looping, handle/2 is never called. Instead, Cowboy will listen
for Erlang messages and forward them to the info/3 function of the
handler. If a timeout is defined, Cowboy will also close the connection
when no message has been received for Timeout milliseconds.
The info/3 function is defined as info(Msg, Req, State). It can return
either of the following tuples:
- {ok, Req, State}
- {loop, Req, State}
- {loop, Req, State, hibernate}
The first one ends the connection, calling terminate/2 before closing.
The others continue the loop.
Loops are useful when writing long-polling handlers that need to wait
and don't expect to receive anything. Therefore it is recommended to
set a timeout to close the connection if nothing arrives after a while
and to enable hibernate everywhere.
Normal HTTP handlers shouldn't need to use this and as such info/3
was made optional.
This change allows application developers to refuse websocket upgrades
by returning {shutdown, Req}. The application can also send a reply
with a custom error before returning from websocket_init/3, otherwise
an error 400 is sent.
Note that right now Cowboy closes the connection immediately. Also note
that neither terminate/3 nor websocket_terminate/3 will be called when
the connection is shutdown by websocket_init/3.
Now Cowboy checks headers sent to the client for the 'Connection'
header value, parses it, and checks whether it contains a 'close'
or 'keep-alive' value. It makes sure to close or keep the connection
alive depending on the value found there, if any.
Also change chunked replies to not close the connection by default
unless the application requests it.
If the websocket frame handling code in cowboy_http_websocket receives
only 1 byte at a time, it fails with a badmatch in
cowboy_http_websocket:websocket_data/4. This commit fixes the problem
and introduces a test of the correct behaviour.
The issue was that we were calling erlang:hibernate before a
receive .. after .. end call. Erlang hibernates the process before
reaching the receive instruction and we therefore couldn't enter
the after clause when hibernating.
This is now fixed by using erlang:send_after instead and receiving
that message instead of using an after clause.
Browsers get mad that the returned location address is not the same
as what they sent, since the :(80|443) is stripped.
Add a simple eunit test due to existing ct websockets tests not
covering this case.
The server now does a single recv (or more, but only if needed)
which is then sent to erlang:decode_packet/3 multiple times. Since
most requests are smaller than the default MTU on many platforms,
we benefit from this greatly.
In the case of requests with a body, the server usually read at
least part of the body on the first recv. This is bufferized
properly and used when later retrieving the body.
In the case of pipelined requests, we can end up reading many
requests in a single recv, which are then handled properly using
only the buffer containing the received data.
