| Age | Commit message (Collapse) | Author |
|---|
|
Mostly useful for REST, which has a ton. This is an initial
commit, it still needs to be tested, but it's time to sleep.
|
|
Yes I know the function never returns. :-)
|
|
|
|
|
|
|
|
Now everywhere in Cowboy when we want to stop something we return
a 'stop' tuple instead of one of the many choices depending on
context that we had before.
This particular change affects middlewares, sub protocols and
REST handlers which were using 'halt' to stop processing.
|
|
This callback was simply useless.
|
|
This change simplifies a little more the sub protocols mechanism.
Aliases have been removed. The renaming of loop handlers as long
polling handlers has been reverted.
Plain HTTP handlers now simply do their work in the init/2
callback. There is no specific code for them.
Loop handlers now follow the same return value as Websocket,
they use ok to continue and shutdown to stop.
Terminate reasons for all handler types have been documented.
The terminate callback is now appropriately called in all cases
(or should be).
Behaviors for all handler types have been moved in the module
that implement them. This means that cowboy_handler replaces
the cowboy_http_handler behavior, and similarly cowboy_loop
replaces cowboy_loop_handler, cowboy_websocket replaces
cowboy_websocket_handler. Finally cowboy_rest now has the
start of a behavior in it and will have the full list of
optional callbacks defined once Erlang 18.0 gets released.
The guide has been reorganized and should be easier to follow.
|
|
This set of changes is the first step to simplify the
writing of handlers, by removing some extraneous
callbacks and making others optional.
init/3 is now init/2, its first argument being removed.
rest_init/2 and rest_terminate/2 have been removed.
websocket_init/3 and websocket_terminate/3 have been removed.
terminate/3 is now optional. It is called regardless of
the type of handler, including rest and websocket.
The return value of init/2 changed. It now returns
{Mod, Req, Opts} with Mod being either one of the four
handler type or a custom module. It can also return extra
timeout and hibernate options.
The signature for sub protocols has changed, they now
receive these extra timeout and hibernate options.
Loop handlers are now implemented in cowboy_long_polling,
and will be renamed throughout the project in a future commit.
|
|
Simplify the interface for most cowboy_req functions. They all return
a single value except the four body reading functions. The reply functions
now only return a Req value.
Access functions do not return a Req anymore.
Functions that used to cache results do not have a cache anymore.
The interface for accessing query string and cookies has therefore
been changed.
There are now three query string functions: qs/1 provides access
to the raw query string value; parse_qs/1 returns the query string
as a list of key/values; match_qs/2 returns a map containing the
values requested in the second argument, after applying constraints
and default value.
Similarly, there are two cookie functions: parse_cookies/1 and
match_cookies/2. More match functions will be added in future commits.
None of the functions return an error tuple anymore. It either works
or crashes. Cowboy will attempt to provide an appropriate status code
in the response of crashed handlers.
As a result, the content decode function has its return value changed
to a simple binary, and the body reading functions only return on success.
|
|
This is a first step to improve the HTTP status codes returned
by Cowboy on crashes. We will tweak it over time.
Also fixes a small bug where two replies may have been sent
when using loop handlers under rare conditions.
|
|
422 is undefined for HTTP and interpreted as 400.
|
|
|
|
|
|
|
|
|
|
|
|
Regardless of whether a location header has been set, as explained
in the HTTP RFC.
|
|
When something went wrong in a handler we used to report errors
and then terminate the process normally. This doesn't work so
well with links which won't detect failure.
Now we still catch the error, but throw another one with more
details on why it happened, including the Req object information
and the stacktrace. Ranch will then print an error message with
all this information.
Because we crash directly, this also means that we will not hog
resources unnecessarily for too long when something bad happens.
|
|
|
|
This stacktrace is very useful in the `onresponse` hook. For example:
```erlang
internal_error_hook(500, Headers, <<>>, Req) ->
StackTrace = erlang:get_stacktrace(),
Headers0 = [{N, V} || {N, V} <- Headers, N =/= <<"content-length">>],
Body = io_lib:format("~p", [StackTrace]),
{ok, Req0} = cowboy_req:reply(500, Headers0, Body, Req),
Req0;
internal_error_hook(Status, Headers, Body, Req) ->
{ok, Req0} = cowboy_req:reply(Status, Headers, Body, Req),
Req0.
```
|
|
|
|
It was added all the time when * was missing, the RFC specifies it
should only be added if it wasn't already present, though.
|
|
It incorrectly returned a tuple containing the charset and an
associated quality which wasn't being used.
|
|
|
|
|
|
|
|
Adds a new type of streaming response fun. It can be set in a similar
way to a streaming body fun with known length:
Req2 = cowboy_req:set_resp_body_fun(chunked, StreamFun, Req)
The fun, StreamFun, should accept a fun as its single argument. This
fun, ChunkFun, is used to send chunks of iodata:
ok = ChunkFun(IoData)
ChunkFun should not be called with an empty binary or iolist as this
will cause HTTP 1.1 clients to believe the stream is over. The final (0
length) chunk will be sent automatically - even if it has already been
sent - assuming no exception is raised.
Also note that the connection will close after the last chunk for HTTP
1.0 clients.
|
|
|
|
|
|
|
|
The resource accept callback can trigger the following responses:
* returns true, new resource, location header set: 201
* returns true, otherwise: 200, 204 or 300 (depends on body)
* returns false: 422
* returns URL, new resource: 201
* returns URL, otherwise: 303
|
|
|
|
It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
|
|
|
|
For the simple reason that the REST code does nothing about
them.
|
|
Instead it will always go through content_types_accepted and it is
up to the resource code to do any creation and to return the created
path if the method is POST and the client should be redirected to the
created resource's location.
This removes the meta value 'put_path' as it is not needed anymore.
This fixes an issue with PATCH where content types were not normalized.
|
|
For get_type_provided:
'*' will be match any parameters of media-range in "accept" header.
If '*' matched, then '*' is replaced by the matching parameters.
If Accept header is missing and '*' using, then in media_type in parameters
will be '*' and reply content-type will be without any parameters.
For content_types_accepted:
'*' will be match any parameters in "content-type" header.
|
|
|
|
Also improves error reporting.
|
|
Fix #414
|
|
Conflicts:
src/cowboy_rest.erl
|
|
|
|
|
|
|
|
|
|
This allows streaming a body without knowing the length in advance.
Also allows {stream, StreamFun} response body in the REST code.
|
|
Middlewares allow customizing the request processing.
All existing Cowboy project are incompatible with this commit.
You need to change `{dispatch, Dispatch}` in the protocol options
to `{env, [{dispatch, Dispatch}]}` to fix your code.
|
|
Using a 4xx error would be more appropriate for this since the server is parsing the content from the client and needs to let the client know the data is malformed (not the actual HTTP request but i.e. JSON semantics). The definition for 422 is described in [RFC 4918](https://tools.ietf.org/html/rfc4918#section-11.2)
|
|
The purpose of this patch is to make the arguments cowboy passes to
error_logger more consistent. With this patch there's only 3 variations
on the error_logger argument list; a 5 element list, an 8 element list
and a 10 element list. In all cases, the first 3 arguments are the
Module, Function and Arity of the function being called and the
second-to-last argument is always the Request. Additionally, for lists
longer than 5 elements, the last argument is always the stack-trace.
The added consistency of the argument ordering makes it much easier to
write code in lager's error_logger handler to catch these messages and
write a pretty one-liner (while writing the full message to the
crash.log).
|
