umgeher/cowboy
0
Fork 0
mirror of https://github.com/ninenines/cowboy.git synced 2025-07-14 20:30:23 +00:00
Code Issues Wiki Activity
cowboy/src/cowboy_rest.erl

1159 lines
39 KiB
Erlang
Raw Normal View History

Welcome to 2017
2017-01-02 19:36:36 +01:00
%% Copyright (c) 2011-2017, Loïc Hoguin <essen@ninenines.eu>
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%%
%% Permission to use, copy, modify, and/or distribute this software for any
%% purpose with or without fee is hereby granted, provided that the above
%% copyright notice and this permission notice appear in all copies.
%%
%% THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
%% WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
%% MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
%% ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
%% WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
%% ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
%% OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
REST is no longer experimental
2013-04-20 17:46:29 +02:00
%% Originally based on the Webmachine Diagram from Alan Dean and
%% Justin Sheehy.
Rename cowboy_http_rest to cowboy_rest
2012-08-27 13:39:59 +02:00
-module(cowboy_rest).
Add sub protocol behaviour
2013-02-15 00:53:40 +00:00
-behaviour(cowboy_sub_protocol).
Have only one -export and -export_type per line This should make easier spotting additions and removals in commits.
2012-08-27 12:16:07 +02:00
Allow passing options to sub protocols 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.
2017-02-18 18:26:20 +01:00
-export([upgrade/4]).
-export([upgrade/5]).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add optional callbacks 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.
2015-07-27 23:58:58 +02:00
%% Common handler callbacks.
Improve handler interface and documentation 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.
2014-09-30 20:12:13 +03:00
-callback init(Req, any())
-> {ok | module(), Req, any()}
Allow passing options to sub protocols 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.
2017-02-18 18:26:20 +01:00
| {module(), Req, any(), any()}
Improve handler interface and documentation 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.
2014-09-30 20:12:13 +03:00
when Req::cowboy_req:req().
Add optional callbacks 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.
2015-07-27 23:58:58 +02:00
-callback terminate(any(), cowboy_req:req(), any()) -> ok.
-optional_callbacks([terminate/3]).
%% REST handler callbacks.
-callback allowed_methods(Req, State)
-> {[binary()], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([allowed_methods/2]).
-callback allow_missing_post(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([allow_missing_post/2]).
-callback charsets_provided(Req, State)
-> {[binary()], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([charsets_provided/2]).
-callback content_types_accepted(Req, State)
-> {[{binary() | {binary(), binary(), '*' | [{binary(), binary()}]}, atom()}], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([content_types_accepted/2]).
-callback content_types_provided(Req, State)
-> {[{binary() | {binary(), binary(), '*' | [{binary(), binary()}]}, atom()}], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([content_types_provided/2]).
-callback delete_completed(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([delete_completed/2]).
-callback delete_resource(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([delete_resource/2]).
-callback expires(Req, State)
-> {calendar:datetime() | binary() | undefined, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([expires/2]).
-callback forbidden(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([forbidden/2]).
-callback generate_etag(Req, State)
-> {binary() | {weak | strong, binary()}, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([generate_etag/2]).
-callback is_authorized(Req, State)
-> {true | {false, iodata()}, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([is_authorized/2]).
-callback is_conflict(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([is_conflict/2]).
-callback known_methods(Req, State)
-> {[binary()], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([known_methods/2]).
-callback languages_provided(Req, State)
-> {[binary()], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([languages_provided/2]).
-callback last_modified(Req, State)
-> {calendar:datetime(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([last_modified/2]).
-callback malformed_request(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([malformed_request/2]).
-callback moved_permanently(Req, State)
-> {{true, iodata()} | false, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([moved_permanently/2]).
-callback moved_temporarily(Req, State)
-> {{true, iodata()} | false, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([moved_temporarily/2]).
-callback multiple_choices(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([multiple_choices/2]).
-callback options(Req, State)
-> {ok, Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([options/2]).
-callback previously_existed(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([previously_existed/2]).
-callback resource_exists(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([resource_exists/2]).
-callback service_available(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([service_available/2]).
-callback uri_too_long(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([uri_too_long/2]).
-callback valid_content_headers(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([valid_content_headers/2]).
-callback valid_entity_length(Req, State)
-> {boolean(), Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([valid_entity_length/2]).
-callback variances(Req, State)
-> {[binary()], Req, State}
| {stop, Req, State}
when Req::cowboy_req:req(), State::any().
-optional_callbacks([variances/2]).
%% End of REST callbacks. Whew!
Improve handler interface and documentation 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.
2014-09-30 20:12:13 +03:00
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
-record(state, {
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
method = undefined :: binary(),
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% Handler.
handler :: atom(),
handler_state :: any(),
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
%% Allowed methods. Only used for OPTIONS requests.
Numerous Dialyzer fixes
2017-01-02 16:47:16 +01:00
allowed_methods :: [binary()] | undefined,
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% Media type.
content_types_p = [] ::
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
[{binary() | {binary(), binary(), [{binary(), binary()}] | '*'},
atom()}],
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
content_type_a :: undefined
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
| {binary() | {binary(), binary(), [{binary(), binary()}] | '*'},
atom()},
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% Language.
languages_p = [] :: [binary()],
language_a :: undefined | binary(),
%% Charset.
charsets_provided/2 returns a list of charsets It incorrectly returned a tuple containing the charset and an associated quality which wasn't being used.
2013-05-16 17:32:07 +02:00
charsets_p = [] :: [binary()],
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
charset_a :: undefined | binary(),
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
%% Whether the resource exists.
exists = false :: boolean(),
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% Cached resource calls.
Tests and fixes for the generate_etag/2 callback 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.
2012-02-28 18:35:26 +01:00
etag :: undefined | no_call | {strong | weak, binary()},
Use calendar date and time types exported since R14B04 Removes the cowboy_clock:date/0, time/0 and datetime/0 exported types.
2011-12-26 10:13:30 +01:00
last_modified :: undefined | no_call | calendar:datetime(),
Allow users to pass a raw binary() as the expires header.
2014-06-06 02:37:24 -04:00
expires :: undefined | no_call | calendar:datetime() | binary()
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
}).
Allow passing options to sub protocols 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.
2017-02-18 18:26:20 +01:00
-spec upgrade(Req, Env, module(), any())
Update specs that were too wide
2014-06-30 17:36:43 +02:00
-> {ok, Req, Env} when Req::cowboy_req:req(), Env::cowboy_middleware:env().
Allow passing options to sub protocols 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.
2017-02-18 18:26:20 +01:00
upgrade(Req0, Env, Handler, HandlerState) ->
Remove the environment from cowboy_rest crash reports It only serves to pollute logs.
2016-06-06 17:30:13 +02:00
Method = cowboy_req:method(Req0),
{ok, Req, Result} = service_available(Req0, #state{method=Method,
handler=Handler, handler_state=HandlerState}),
Remaining Dialyzer fixes
2017-01-02 18:27:03 +01:00
{ok, Req, Env#{result => Result}}.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Allow passing options to sub protocols 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.
2017-02-18 18:26:20 +01:00
-spec upgrade(Req, Env, module(), any(), any())
-> {ok, Req, Env} when Req::cowboy_req:req(), Env::cowboy_middleware:env().
%% cowboy_rest takes no options.
upgrade(Req, Env, Handler, HandlerState, _Opts) ->
upgrade(Req, Env, Handler, HandlerState).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
service_available(Req, State) ->
expect(Req, State, service_available, true, fun known_methods/2, 503).
Clarify docs for known_methods and allowed_methods.
2012-10-13 15:15:15 -07:00
%% known_methods/2 should return a list of binary methods.
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
known_methods(Req, State=#state{method=Method}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case call(Req, State, known_methods) of
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
no_call when Method =:= <<"HEAD">>; Method =:= <<"GET">>;
Method =:= <<"POST">>; Method =:= <<"PUT">>;
Don't accept TRACE or CONNECT methods by default in REST For the simple reason that the REST code does nothing about them.
2013-04-11 21:25:35 +02:00
Method =:= <<"PATCH">>; Method =:= <<"DELETE">>;
Method =:= <<"OPTIONS">> ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
next(Req, State, fun uri_too_long/2);
Add default values to known_methods and allowed_methods Only allowing HEAD and GET requests by default.
2011-12-08 18:54:20 +01:00
no_call ->
next(Req, State, 501);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{List, Req2, HandlerState} ->
State2 = State#state{handler_state=HandlerState},
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case lists:member(Method, List) of
true -> next(Req2, State2, fun uri_too_long/2);
false -> next(Req2, State2, 501)
end
end.
uri_too_long(Req, State) ->
expect(Req, State, uri_too_long, false, fun allowed_methods/2, 414).
Clarify docs for known_methods and allowed_methods.
2012-10-13 15:15:15 -07:00
%% allowed_methods/2 should return a list of binary methods.
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
allowed_methods(Req, State=#state{method=Method}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case call(Req, State, allowed_methods) of
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
no_call when Method =:= <<"HEAD">>; Method =:= <<"GET">> ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
next(Req, State, fun malformed_request/2);
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
no_call when Method =:= <<"OPTIONS">> ->
next(Req, State#state{allowed_methods=
[<<"HEAD">>, <<"GET">>, <<"OPTIONS">>]},
fun malformed_request/2);
Add default values to known_methods and allowed_methods Only allowing HEAD and GET requests by default.
2011-12-08 18:54:20 +01:00
no_call ->
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
method_not_allowed(Req, State,
[<<"HEAD">>, <<"GET">>, <<"OPTIONS">>]);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{List, Req2, HandlerState} ->
State2 = State#state{handler_state=HandlerState},
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case lists:member(Method, List) of
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
true when Method =:= <<"OPTIONS">> ->
Fix a bug in REST when allowed_methods is defined when method is OPTIONS
2013-04-29 16:36:54 +02:00
next(Req2, State2#state{allowed_methods=List},
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
fun malformed_request/2);
true ->
next(Req2, State2, fun malformed_request/2);
false ->
method_not_allowed(Req2, State2, List)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end
end.
Empty methods list allowed
2013-04-30 18:22:40 +04:00
method_not_allowed(Req, State, []) ->
Req2 = cowboy_req:set_resp_header(<<"allow">>, <<>>, Req),
respond(Req2, State, 405);
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
method_not_allowed(Req, State, Methods) ->
Build Allow header with a binary comprehension
2013-04-15 22:15:45 +02:00
<< ", ", Allow/binary >> = << << ", ", M/binary >> || M <- Methods >>,
Req2 = cowboy_req:set_resp_header(<<"allow">>, Allow, Req),
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
respond(Req2, State, 405).
malformed_request(Req, State) ->
expect(Req, State, malformed_request, false, fun is_authorized/2, 400).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% is_authorized/2 should return true or {false, WwwAuthenticateHeader}.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
is_authorized(Req, State) ->
case call(Req, State, is_authorized) of
no_call ->
forbidden(Req, State);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{true, Req2, HandlerState} ->
forbidden(Req2, State#state{handler_state=HandlerState});
{{false, AuthHead}, Req2, HandlerState} ->
Improve consistency of return types for cowboy_req API The signature of parse_header, body_qs, multipart_data and the set_resp_* functions has changed. See the cowboy_req module edoc for more details.
2012-09-16 03:51:07 +02:00
Req3 = cowboy_req:set_resp_header(
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
<<"www-authenticate">>, AuthHead, Req2),
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
respond(Req3, State#state{handler_state=HandlerState}, 401)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
forbidden(Req, State) ->
expect(Req, State, forbidden, false, fun valid_content_headers/2, 403).
valid_content_headers(Req, State) ->
expect(Req, State, valid_content_headers, true,
Remove the REST known_content_type callback This callback was simply useless.
2014-10-03 18:52:14 +03:00
fun valid_entity_length/2, 501).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
valid_entity_length(Req, State) ->
expect(Req, State, valid_entity_length, true, fun options/2, 413).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% If you need to add additional headers to the response at this point,
%% you should do it directly in the options/2 call using set_resp_headers.
Build Allow header with a binary comprehension
2013-04-15 22:15:45 +02:00
options(Req, State=#state{allowed_methods=Methods, method= <<"OPTIONS">>}) ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
case call(Req, State, options) of
Empty methods list allowed
2013-04-30 18:22:40 +04:00
no_call when Methods =:= [] ->
Req2 = cowboy_req:set_resp_header(<<"allow">>, <<>>, Req),
respond(Req2, State, 200);
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
no_call ->
Build Allow header with a binary comprehension
2013-04-15 22:15:45 +02:00
<< ", ", Allow/binary >>
= << << ", ", M/binary >> || M <- Methods >>,
Req2 = cowboy_req:set_resp_header(<<"allow">>, Allow, Req),
Add default operations for OPTIONS method in REST It defaults to setting the Allow header to "HEAD, GET, OPTIONS".
2013-04-12 18:20:41 +02:00
respond(Req2, State, 200);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
{ok, Req2, HandlerState} ->
respond(Req2, State#state{handler_state=HandlerState}, 200)
end;
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
options(Req, State) ->
content_types_provided(Req, State).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% content_types_provided/2 should return a list of content types and their
%% associated callback function as a tuple: {{Type, SubType, Params}, Fun}.
%% Type and SubType are the media type as binary. Params is a list of
%% Key/Value tuple, with Key and Value a binary. Fun is the name of the
%% callback that will be used to return the content of the response. It is
%% given as an atom.
%%
%% An example of such return value would be:
%% {{<<"text">>, <<"html">>, []}, to_html}
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
%%
%% Note that it is also possible to return a binary content type that will
%% then be parsed by Cowboy. However note that while this may make your
Cosmetic changes to various documentation files
2012-11-27 16:24:08 +01:00
%% resources a little more readable, this is a lot less efficient.
%%
%% An example of such return value would be:
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
%% {<<"text/html">>, to_html}
Introduce cowboy_req:set_meta/3 to set request metadata
2012-09-15 22:51:37 +02:00
content_types_provided(Req, State) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case call(Req, State, content_types_provided) of
no_call ->
Add default CTP: "text/html" maps to `to_html`
2013-04-26 18:34:01 +07:00
State2 = State#state{
content_types_p=[{{<<"text">>, <<"html">>, '*'}, to_html}]},
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
try cowboy_req:parse_header(<<"accept">>, Req) of
undefined ->
Add default CTP: "text/html" maps to `to_html`
2013-04-26 18:34:01 +07:00
languages_provided(
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
Req#{media_type => {<<"text">>, <<"html">>, []}},
Add default CTP: "text/html" maps to `to_html`
2013-04-26 18:34:01 +07:00
State2#state{content_type_a={{<<"text">>, <<"html">>, []}, to_html}});
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
Accept ->
choose_media_type(Req, State2, prioritize_accept(Accept))
catch _:_ ->
respond(Req, State2, 400)
Add default CTP: "text/html" maps to `to_html`
2013-04-26 18:34:01 +07:00
end;
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
{[], Req2, HandlerState} ->
not_acceptable(Req2, State#state{handler_state=HandlerState});
{CTP, Req2, HandlerState} ->
Fix indenting issues in `cowboy_rest.erl`
2013-04-26 18:34:10 +07:00
CTP2 = [normalize_content_types(P) || P <- CTP],
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
State2 = State#state{
handler_state=HandlerState, content_types_p=CTP2},
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
try cowboy_req:parse_header(<<"accept">>, Req2) of
undefined ->
Add meta/2 and meta/3 to cowboy_http_req to save useful protocol information * cowboy_http_protocol now defines 'websocket_version' as metadata. * cowboy_http_rest now defines 'media_type', 'language', 'charset' as metadata.
2011-12-19 09:44:24 +01:00
{PMT, _Fun} = HeadCTP = hd(CTP2),
languages_provided(
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
Req2#{media_type => PMT},
Add meta/2 and meta/3 to cowboy_http_req to save useful protocol information * cowboy_http_protocol now defines 'websocket_version' as metadata. * cowboy_http_rest now defines 'media_type', 'language', 'charset' as metadata.
2011-12-19 09:44:24 +01:00
State2#state{content_type_a=HeadCTP});
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
Accept ->
choose_media_type(Req2, State2, prioritize_accept(Accept))
catch _:_ ->
respond(Req2, State2, 400)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end
end.
REST: Normalize content types accepted Same as content types provided, we accept the <<"application/json">> form.
2012-07-21 19:02:01 +02:00
normalize_content_types({ContentType, Callback})
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
when is_binary(ContentType) ->
Use cowlib for parsing headers; remove cowboy_http
2015-02-04 16:18:28 +01:00
{cow_http_hd:parse_content_type(ContentType), Callback};
Remove process_post, post_is_create, create_path, created_path callbacks 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.
2013-04-11 17:59:54 +02:00
normalize_content_types(Normalized) ->
Normalized.
adds webmachine format content type handling
2011-12-09 22:58:15 -08:00
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
prioritize_accept(Accept) ->
lists:sort(
fun ({MediaTypeA, Quality, _AcceptParamsA},
{MediaTypeB, Quality, _AcceptParamsB}) ->
%% Same quality, check precedence in more details.
prioritize_mediatype(MediaTypeA, MediaTypeB);
({_MediaTypeA, QualityA, _AcceptParamsA},
{_MediaTypeB, QualityB, _AcceptParamsB}) ->
%% Just compare the quality.
QualityA > QualityB
end, Accept).
%% Media ranges can be overridden by more specific media ranges or
%% specific media types. If more than one media range applies to a given
%% type, the most specific reference has precedence.
%%
%% We always choose B over A when we can't decide between the two.
prioritize_mediatype({TypeA, SubTypeA, ParamsA}, {TypeB, SubTypeB, ParamsB}) ->
case TypeB of
TypeA ->
case SubTypeB of
SubTypeA -> length(ParamsA) > length(ParamsB);
<<"*">> -> true;
_Any -> false
end;
<<"*">> -> true;
_Any -> false
end.
%% Ignoring the rare AcceptParams. Not sure what should be done about them.
choose_media_type(Req, State, []) ->
not_acceptable(Req, State);
choose_media_type(Req, State=#state{content_types_p=CTP},
[MediaType|Tail]) ->
match_media_type(Req, State, Tail, CTP, MediaType).
match_media_type(Req, State, Accept, [], _MediaType) ->
choose_media_type(Req, State, Accept);
Fixes match_media_type in cowboy_http_rest Based on the patch from Heinz N. Gies. The main change is that his patch accept values such as */plain which we do not want. Fixes issue #105.
2011-12-12 08:18:38 +01:00
match_media_type(Req, State, Accept, CTP,
MediaType = {{<<"*">>, <<"*">>, _Params_A}, _QA, _APA}) ->
match_media_type_params(Req, State, Accept, CTP, MediaType);
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
match_media_type(Req, State, Accept,
Fixes match_media_type in cowboy_http_rest Based on the patch from Heinz N. Gies. The main change is that his patch accept values such as */plain which we do not want. Fixes issue #105.
2011-12-12 08:18:38 +01:00
CTP = [{{Type, SubType_P, _PP}, _Fun}|_Tail],
MediaType = {{Type, SubType_A, _PA}, _QA, _APA})
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
when SubType_P =:= SubType_A; SubType_A =:= <<"*">> ->
Fixes match_media_type in cowboy_http_rest Based on the patch from Heinz N. Gies. The main change is that his patch accept values such as */plain which we do not want. Fixes issue #105.
2011-12-12 08:18:38 +01:00
match_media_type_params(Req, State, Accept, CTP, MediaType);
match_media_type(Req, State, Accept, [_Any|Tail], MediaType) ->
match_media_type(Req, State, Accept, Tail, MediaType).
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
match_media_type_params(Req, State, _Accept,
[Provided = {{TP, STP, '*'}, _Fun}|_Tail],
{{_TA, _STA, Params_A}, _QA, _APA}) ->
PMT = {TP, STP, Params_A},
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
languages_provided(Req#{media_type => PMT},
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
State#state{content_type_a=Provided});
Introduce cowboy_req:set_meta/3 to set request metadata
2012-09-15 22:51:37 +02:00
match_media_type_params(Req, State, Accept,
Add meta/2 and meta/3 to cowboy_http_req to save useful protocol information * cowboy_http_protocol now defines 'websocket_version' as metadata. * cowboy_http_rest now defines 'media_type', 'language', 'charset' as metadata.
2011-12-19 09:44:24 +01:00
[Provided = {PMT = {_TP, _STP, Params_P}, _Fun}|Tail],
Fixes match_media_type in cowboy_http_rest Based on the patch from Heinz N. Gies. The main change is that his patch accept values such as */plain which we do not want. Fixes issue #105.
2011-12-12 08:18:38 +01:00
MediaType = {{_TA, _STA, Params_A}, _QA, _APA}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case lists:sort(Params_P) =:= lists:sort(Params_A) of
true ->
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
languages_provided(Req#{media_type => PMT},
Add meta/2 and meta/3 to cowboy_http_req to save useful protocol information * cowboy_http_protocol now defines 'websocket_version' as metadata. * cowboy_http_rest now defines 'media_type', 'language', 'charset' as metadata.
2011-12-19 09:44:24 +01:00
State#state{content_type_a=Provided});
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
false ->
match_media_type(Req, State, Accept, Tail, MediaType)
Fixes match_media_type in cowboy_http_rest Based on the patch from Heinz N. Gies. The main change is that his patch accept values such as */plain which we do not want. Fixes issue #105.
2011-12-12 08:18:38 +01:00
end.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% languages_provided should return a list of binary values indicating
%% which languages are accepted by the resource.
%%
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% @todo I suppose we should also ask the resource if it wants to
%% set a language itself or if it wants it to be automatically chosen.
languages_provided(Req, State) ->
case call(Req, State, languages_provided) of
no_call ->
charsets_provided(Req, State);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{[], Req2, HandlerState} ->
not_acceptable(Req2, State#state{handler_state=HandlerState});
{LP, Req2, HandlerState} ->
State2 = State#state{handler_state=HandlerState, languages_p=LP},
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
case cowboy_req:parse_header(<<"accept-language">>, Req2) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
undefined ->
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
set_language(Req2, State2#state{language_a=hd(LP)});
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
AcceptLanguage ->
AcceptLanguage2 = prioritize_languages(AcceptLanguage),
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
choose_language(Req2, State2, AcceptLanguage2)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end
end.
%% A language-range matches a language-tag if it exactly equals the tag,
%% or if it exactly equals a prefix of the tag such that the first tag
%% character following the prefix is "-". The special range "*", if
%% present in the Accept-Language field, matches every tag not matched
%% by any other range present in the Accept-Language field.
%%
%% @todo The last sentence probably means we should always put '*'
%% at the end of the list.
prioritize_languages(AcceptLanguages) ->
lists:sort(
fun ({_TagA, QualityA}, {_TagB, QualityB}) ->
QualityA > QualityB
end, AcceptLanguages).
choose_language(Req, State, []) ->
not_acceptable(Req, State);
choose_language(Req, State=#state{languages_p=LP}, [Language|Tail]) ->
match_language(Req, State, Tail, LP, Language).
match_language(Req, State, Accept, [], _Language) ->
choose_language(Req, State, Accept);
match_language(Req, State, _Accept, [Provided|_Tail], {'*', _Quality}) ->
set_language(Req, State#state{language_a=Provided});
match_language(Req, State, _Accept, [Provided|_Tail], {Provided, _Quality}) ->
set_language(Req, State#state{language_a=Provided});
match_language(Req, State, Accept, [Provided|Tail],
Language = {Tag, _Quality}) ->
Length = byte_size(Tag),
case Provided of
<< Tag:Length/binary, $-, _Any/bits >> ->
set_language(Req, State#state{language_a=Provided});
_Any ->
match_language(Req, State, Accept, Tail, Language)
end.
Introduce cowboy_req:set_meta/3 to set request metadata
2012-09-15 22:51:37 +02:00
set_language(Req, State=#state{language_a=Language}) ->
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
Req2 = cowboy_req:set_resp_header(<<"content-language">>, Language, Req),
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
charsets_provided(Req2#{language => Language}, State).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% charsets_provided should return a list of binary values indicating
%% which charsets are accepted by the resource.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
charsets_provided(Req, State) ->
case call(Req, State, charsets_provided) of
no_call ->
set_content_type(Req, State);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{[], Req2, HandlerState} ->
not_acceptable(Req2, State#state{handler_state=HandlerState});
{CP, Req2, HandlerState} ->
State2 = State#state{handler_state=HandlerState, charsets_p=CP},
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
case cowboy_req:parse_header(<<"accept-charset">>, Req2) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
undefined ->
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
set_content_type(Req2, State2#state{charset_a=hd(CP)});
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
AcceptCharset ->
AcceptCharset2 = prioritize_charsets(AcceptCharset),
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
choose_charset(Req2, State2, AcceptCharset2)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end
end.
%% The special value "*", if present in the Accept-Charset field,
%% matches every character set (including ISO-8859-1) which is not
%% mentioned elsewhere in the Accept-Charset field. If no "*" is present
%% in an Accept-Charset field, then all character sets not explicitly
%% mentioned get a quality value of 0, except for ISO-8859-1, which gets
%% a quality value of 1 if not explicitly mentioned.
prioritize_charsets(AcceptCharsets) ->
AcceptCharsets2 = lists:sort(
fun ({_CharsetA, QualityA}, {_CharsetB, QualityB}) ->
QualityA > QualityB
end, AcceptCharsets),
case lists:keymember(<<"*">>, 1, AcceptCharsets2) of
true -> AcceptCharsets2;
The charset iso-8859-1 is added only if not explicitely mentioned It was added all the time when * was missing, the RFC specifies it should only be added if it wasn't already present, though.
2013-05-16 17:38:29 +02:00
false ->
case lists:keymember(<<"iso-8859-1">>, 1, AcceptCharsets2) of
true -> AcceptCharsets2;
false -> [{<<"iso-8859-1">>, 1000}|AcceptCharsets2]
end
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
choose_charset(Req, State, []) ->
not_acceptable(Req, State);
choose_charset(Req, State=#state{charsets_p=CP}, [Charset|Tail]) ->
match_charset(Req, State, Tail, CP, Charset).
match_charset(Req, State, Accept, [], _Charset) ->
choose_charset(Req, State, Accept);
charsets_provided/2 returns a list of charsets It incorrectly returned a tuple containing the charset and an associated quality which wasn't being used.
2013-05-16 17:32:07 +02:00
match_charset(Req, State, _Accept, [Provided|_], {Provided, _}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
set_content_type(Req, State#state{charset_a=Provided});
REST: Fix charset matching
2012-07-21 19:00:52 +02:00
match_charset(Req, State, Accept, [_|Tail], Charset) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
match_charset(Req, State, Accept, Tail, Charset).
Introduce cowboy_req:set_meta/3 to set request metadata
2012-09-15 22:51:37 +02:00
set_content_type(Req, State=#state{
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
content_type_a={{Type, SubType, Params}, _Fun},
charset_a=Charset}) ->
ParamsBin = set_content_type_build_params(Params, []),
ContentType = [Type, <<"/">>, SubType, ParamsBin],
ContentType2 = case Charset of
undefined -> ContentType;
Charset -> [ContentType, <<"; charset=">>, Charset]
end,
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
Req2 = cowboy_req:set_resp_header(<<"content-type">>, ContentType2, Req),
Initial commit with connection/streams Breaking changes with previous commit. This is a very large change, and I am giving up on making a single commit that fixes everything. More commits will follow slowly adding back features, introducing new tests and fixing the documentation. This change contains most of the work toward unifying the interface for handling both HTTP/1.1 and HTTP/2. HTTP/1.1 connections are now no longer 1 process per connection; instead by default 1 process per request is also created. This has a number of pros and cons. Because it has cons, we also allow users to use a lower-level API that acts on "streams" (requests/responses) directly at the connection process-level. If performance is a concern, one can always write a stream handler. The performance in this case will be even greater than with Cowboy 1, although all the special handlers are unavailable. When switching to Websocket, after the handler returns from init/2, Cowboy stops the stream and the Websocket protocol takes over the connection process. Websocket then calls websocket_init/2 for any additional initialization such as timers, because the process is different in init/2 and websocket_*/* functions. This however would allow us to use websocket_init/2 for sending messages on connect, instead of sending ourselves a message and be subject to races. Note that websocket_init/2 is optional. This is all a big change and while most of the tests pass, some functionality currently doesn't. SPDY is broken and will be removed soon in favor of HTTP/2. Automatic compression is currently disabled. The cowboy_req interface probably still have a few functions that need to be updated. The docs and examples do not refer the current functionality anymore. Everything will be fixed over time. Feedback is more than welcome. Open a ticket!
2016-02-10 17:28:32 +01:00
encodings_provided(Req2#{charset => Charset}, State).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
set_content_type_build_params('*', []) ->
<<>>;
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
set_content_type_build_params([], []) ->
<<>>;
set_content_type_build_params([], Acc) ->
lists:reverse(Acc);
set_content_type_build_params([{Attr, Value}|Tail], Acc) ->
set_content_type_build_params(Tail, [[Attr, <<"=">>, Value], <<";">>|Acc]).
%% @todo Match for identity as we provide nothing else for now.
%% @todo Don't forget to set the Content-Encoding header when we reply a body
%% and the found encoding is something other than identity.
encodings_provided(Req, State) ->
variances(Req, State).
not_acceptable(Req, State) ->
respond(Req, State, 406).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% variances/2 should return a list of headers that will be added
%% to the Vary response header. The Accept, Accept-Language,
%% Accept-Charset and Accept-Encoding headers do not need to be
%% specified.
%%
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
%% @todo Do Accept-Encoding too when we handle it.
%% @todo Does the order matter?
variances(Req, State=#state{content_types_p=CTP,
languages_p=LP, charsets_p=CP}) ->
update cowboy_http_rest:variances/2 Fix pattern in case statement that was intended to strip away the first comma separating the values in the variance header. Update generation of variance list to use more idiomatic erlang. Pattern match on list structure over using erlang:length/1 to compute length.
2011-12-11 19:57:07 +01:00
Variances = case CTP of
[] -> [];
[_] -> [];
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
[_|_] -> [<<"accept">>]
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end,
update cowboy_http_rest:variances/2 Fix pattern in case statement that was intended to strip away the first comma separating the values in the variance header. Update generation of variance list to use more idiomatic erlang. Pattern match on list structure over using erlang:length/1 to compute length.
2011-12-11 19:57:07 +01:00
Variances2 = case LP of
[] -> Variances;
[_] -> Variances;
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
[_|_] -> [<<"accept-language">>|Variances]
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end,
update cowboy_http_rest:variances/2 Fix pattern in case statement that was intended to strip away the first comma separating the values in the variance header. Update generation of variance list to use more idiomatic erlang. Pattern match on list structure over using erlang:length/1 to compute length.
2011-12-11 19:57:07 +01:00
Variances3 = case CP of
[] -> Variances2;
[_] -> Variances2;
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
[_|_] -> [<<"accept-charset">>|Variances2]
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end,
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try variances(Req, State, Variances3) of
{Variances4, Req2, State2} ->
case [[<<", ">>, V] || V <- Variances4] of
[] ->
resource_exists(Req2, State2);
[[<<", ">>, H]|Variances5] ->
Req3 = cowboy_req:set_resp_header(
<<"vary">>, [H|Variances5], Req2),
resource_exists(Req3, State2)
end
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end.
variances(Req, State, Variances) ->
case unsafe_call(Req, State, variances) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
{Variances, Req, State};
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
{HandlerVariances, Req2, HandlerState} ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
{Variances ++ HandlerVariances, Req2,
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
State#state{handler_state=HandlerState}}
end.
resource_exists(Req, State) ->
expect(Req, State, resource_exists, true,
musnt is not the correct contraction of mustn't - use must_not instead
2012-10-25 15:29:02 -04:00
fun if_match_exists/2, fun if_match_must_not_exist/2).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
if_match_exists(Req, State) ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
State2 = State#state{exists=true},
Don't use decode_packet/3 for parsing the headers Header names are now binaries. Since header names are case insensitive they are all converted to lowercase. For example: <<"content-length">>. The max_line_length option was removed. Three new options have been added instead: * max_request_line_length (defaults to 4096) * max_header_name_length (defaults to 64) * max_header_value_length (defaults to 4096)
2012-09-21 09:18:56 +02:00
case cowboy_req:parse_header(<<"if-match">>, Req) of
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
undefined ->
if_unmodified_since_exists(Req, State2);
'*' ->
if_unmodified_since_exists(Req, State2);
ETagsList ->
if_match(Req, State2, ETagsList)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
if_match(Req, State, EtagsList) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try generate_etag(Req, State) of
REST: If-Match uses strong Etag comparison Weak Etag never matches.
2016-06-06 17:32:04 +02:00
%% Strong Etag comparison: weak Etag never matches.
{{weak, _}, Req2, State2} ->
precondition_failed(Req2, State2);
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
{Etag, Req2, State2} ->
case lists:member(Etag, EtagsList) of
REST: Ignore If...Since if If...Match header exists The If-Modified-Since and If-Unmodified-Since headers are only used when If-None-Match or If-Match were not found, respectively. The latter are preferred by the standard and the former is only there for compatibility with older clients.
2016-06-06 17:33:46 +02:00
true -> if_none_match_exists(Req2, State2);
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
%% Etag may be `undefined' which cannot be a member.
false -> precondition_failed(Req2, State2)
end
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
musnt is not the correct contraction of mustn't - use must_not instead
2012-10-25 15:29:02 -04:00
if_match_must_not_exist(Req, State) ->
Don't use decode_packet/3 for parsing the headers Header names are now binaries. Since header names are case insensitive they are all converted to lowercase. For example: <<"content-length">>. The max_line_length option was removed. Three new options have been added instead: * max_request_line_length (defaults to 4096) * max_header_name_length (defaults to 64) * max_header_value_length (defaults to 4096)
2012-09-21 09:18:56 +02:00
case cowboy_req:header(<<"if-match">>, Req) of
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
undefined -> is_put_to_missing_resource(Req, State);
_ -> precondition_failed(Req, State)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
if_unmodified_since_exists(Req, State) ->
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
try cowboy_req:parse_header(<<"if-unmodified-since">>, Req) of
undefined ->
if_none_match_exists(Req, State);
IfUnmodifiedSince ->
if_unmodified_since(Req, State, IfUnmodifiedSince)
catch _:_ ->
if_none_match_exists(Req, State)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
%% If LastModified is the atom 'no_call', we continue.
if_unmodified_since(Req, State, IfUnmodifiedSince) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try last_modified(Req, State) of
{LastModified, Req2, State2} ->
case LastModified > IfUnmodifiedSince of
true -> precondition_failed(Req2, State2);
false -> if_none_match_exists(Req2, State2)
end
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
if_none_match_exists(Req, State) ->
Don't use decode_packet/3 for parsing the headers Header names are now binaries. Since header names are case insensitive they are all converted to lowercase. For example: <<"content-length">>. The max_line_length option was removed. Three new options have been added instead: * max_request_line_length (defaults to 4096) * max_header_name_length (defaults to 64) * max_header_value_length (defaults to 4096)
2012-09-21 09:18:56 +02:00
case cowboy_req:parse_header(<<"if-none-match">>, Req) of
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
undefined ->
if_modified_since_exists(Req, State);
'*' ->
precondition_is_head_get(Req, State);
EtagsList ->
if_none_match(Req, State, EtagsList)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
if_none_match(Req, State, EtagsList) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try generate_etag(Req, State) of
{Etag, Req2, State2} ->
case Etag of
undefined ->
precondition_failed(Req2, State2);
Etag ->
REST: If-None-Match uses weak Etag comparison Was badly implemented previously.
2016-06-06 17:33:03 +02:00
case is_weak_match(Etag, EtagsList) of
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
true -> precondition_is_head_get(Req2, State2);
REST: Ignore If...Since if If...Match header exists The If-Modified-Since and If-Unmodified-Since headers are only used when If-None-Match or If-Match were not found, respectively. The latter are preferred by the standard and the former is only there for compatibility with older clients.
2016-06-06 17:33:46 +02:00
false -> method(Req2, State2)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
REST: If-None-Match uses weak Etag comparison Was badly implemented previously.
2016-06-06 17:33:03 +02:00
%% Weak Etag comparison: only check the opaque tag.
is_weak_match(_, []) ->
false;
is_weak_match({_, Tag}, [{_, Tag}|_]) ->
true;
is_weak_match(Etag, [_|Tail]) ->
is_weak_match(Etag, Tail).
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
precondition_is_head_get(Req, State=#state{method=Method})
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
when Method =:= <<"HEAD">>; Method =:= <<"GET">> ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
not_modified(Req, State);
precondition_is_head_get(Req, State) ->
precondition_failed(Req, State).
if_modified_since_exists(Req, State) ->
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
try cowboy_req:parse_header(<<"if-modified-since">>, Req) of
undefined ->
method(Req, State);
IfModifiedSince ->
if_modified_since_now(Req, State, IfModifiedSince)
catch _:_ ->
method(Req, State)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
if_modified_since_now(Req, State, IfModifiedSince) ->
case IfModifiedSince > erlang:universaltime() of
true -> method(Req, State);
false -> if_modified_since(Req, State, IfModifiedSince)
end.
if_modified_since(Req, State, IfModifiedSince) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try last_modified(Req, State) of
Fix if_modified_since match of last_modified Correct expected return type from `no_call` to `undefined` in if_modified_since when last_modified callback is not defined. Add an http_SUITE test to catch regressions.
2016-10-06 16:48:34 +08:00
{undefined, Req2, State2} ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
method(Req2, State2);
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
{LastModified, Req2, State2} ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case LastModified > IfModifiedSince of
true -> method(Req2, State2);
false -> not_modified(Req2, State2)
end
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
Add cowboy_req:delete_resp_header/2 Both requested and better for making Req opaque.
2012-09-16 01:55:40 +02:00
not_modified(Req, State) ->
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
Req2 = cowboy_req:delete_resp_header(<<"content-type">>, Req),
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
try set_resp_etag(Req2, State) of
{Req3, State2} ->
try set_resp_expires(Req3, State2) of
{Req4, State3} ->
respond(Req4, State3, 304)
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State2, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
precondition_failed(Req, State) ->
respond(Req, State, 412).
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
is_put_to_missing_resource(Req, State=#state{method= <<"PUT">>}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
moved_permanently(Req, State, fun is_conflict/2);
is_put_to_missing_resource(Req, State) ->
previously_existed(Req, State).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% moved_permanently/2 should return either false or {true, Location}
%% with Location the full new URI of the resource.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
moved_permanently(Req, State, OnFalse) ->
case call(Req, State, moved_permanently) of
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{{true, Location}, Req2, HandlerState} ->
Improve consistency of return types for cowboy_req API The signature of parse_header, body_qs, multipart_data and the set_resp_* functions has changed. See the cowboy_req module edoc for more details.
2012-09-16 03:51:07 +02:00
Req3 = cowboy_req:set_resp_header(
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
<<"location">>, Location, Req2),
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
respond(Req3, State#state{handler_state=HandlerState}, 301);
{false, Req2, HandlerState} ->
OnFalse(Req2, State#state{handler_state=HandlerState});
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
OnFalse(Req, State)
end.
previously_existed(Req, State) ->
expect(Req, State, previously_existed, false,
fun (R, S) -> is_post_to_missing_resource(R, S, 404) end,
fun (R, S) -> moved_permanently(R, S, fun moved_temporarily/2) end).
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% moved_temporarily/2 should return either false or {true, Location}
%% with Location the full new URI of the resource.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
moved_temporarily(Req, State) ->
case call(Req, State, moved_temporarily) of
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{{true, Location}, Req2, HandlerState} ->
Improve consistency of return types for cowboy_req API The signature of parse_header, body_qs, multipart_data and the set_resp_* functions has changed. See the cowboy_req module edoc for more details.
2012-09-16 03:51:07 +02:00
Req3 = cowboy_req:set_resp_header(
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
<<"location">>, Location, Req2),
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
respond(Req3, State#state{handler_state=HandlerState}, 307);
{false, Req2, HandlerState} ->
is_post_to_missing_resource(Req2, State#state{handler_state=HandlerState}, 410);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
is_post_to_missing_resource(Req, State, 410)
end.
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
is_post_to_missing_resource(Req, State=#state{method= <<"POST">>}, OnFalse) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
allow_missing_post(Req, State, OnFalse);
is_post_to_missing_resource(Req, State, OnFalse) ->
respond(Req, State, OnFalse).
allow_missing_post(Req, State, OnFalse) ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
expect(Req, State, allow_missing_post, true, fun accept_resource/2, OnFalse).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
method(Req, State=#state{method= <<"DELETE">>}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
delete_resource(Req, State);
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
method(Req, State=#state{method= <<"PUT">>}) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
is_conflict(Req, State);
Remove process_post, post_is_create, create_path, created_path callbacks 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.
2013-04-11 17:59:54 +02:00
method(Req, State=#state{method=Method})
when Method =:= <<"POST">>; Method =:= <<"PATCH">> ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
accept_resource(Req, State);
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
method(Req, State=#state{method=Method})
Don't use decode_packet/3 for parsing the request-line First step in making all methods and header names binaries to get rid of many inconsistencies caused by decode_packet/3. Methods are all binary now. Note that since they are case sensitive, the usual methods become <<"GET">>, <<"POST">> and so on.
2012-09-20 06:22:51 +02:00
when Method =:= <<"GET">>; Method =:= <<"HEAD">> ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
set_resp_body_etag(Req, State);
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
method(Req, State) ->
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
multiple_choices(Req, State).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% delete_resource/2 should start deleting the resource and return.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
delete_resource(Req, State) ->
Handle delete better when no delete_resource function is implemented
2012-01-23 16:10:41 -06:00
expect(Req, State, delete_resource, false, 500, fun delete_completed/2).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% delete_completed/2 indicates whether the resource has been deleted yet.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
delete_completed(Req, State) ->
expect(Req, State, delete_completed, true, fun has_resp_body/2, 202).
is_conflict(Req, State) ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
expect(Req, State, is_conflict, false, fun accept_resource/2, 409).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% content_types_accepted should return a list of media types and their
%% associated callback functions in the same format as content_types_provided.
%%
%% The callback will then be called and is expected to process the content
Remove process_post, post_is_create, create_path, created_path callbacks 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.
2013-04-11 17:59:54 +02:00
%% pushed to the resource in the request body.
add patch support to cowboy_rest
2012-10-15 17:56:55 -05:00
%%
Remove process_post, post_is_create, create_path, created_path callbacks 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.
2013-04-11 17:59:54 +02:00
%% content_types_accepted SHOULD return a different list
add patch support to cowboy_rest
2012-10-15 17:56:55 -05:00
%% for each HTTP method.
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
accept_resource(Req, State) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
case call(Req, State, content_types_accepted) of
no_call ->
respond(Req, State, 415);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{CTA, Req2, HandlerState} ->
Fix indenting issues in `cowboy_rest.erl`
2013-04-26 18:34:10 +07:00
CTA2 = [normalize_content_types(P) || P <- CTA],
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
State2 = State#state{handler_state=HandlerState},
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
try cowboy_req:parse_header(<<"content-type">>, Req2) of
ContentType ->
choose_content_type(Req2, State2, ContentType, CTA2)
catch _:_ ->
respond(Req2, State2, 415)
rest: reject incorrect content-type header
2013-04-12 09:51:47 +04:00
end
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
Merge branch 'content-type-accepted-asterisk-atom' of https://github.com/dysinger/cowboy Added a comment explaining the '*' always matching.
2012-03-13 00:46:56 +01:00
%% The special content type '*' will always match. It can be used as a
%% catch-all content type for accepting any kind of request content.
%% Note that because it will always match, it should be the last of the
%% list of content types, otherwise it'll shadow the ones following.
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
choose_content_type(Req, State, _ContentType, []) ->
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
respond(Req, State, 415);
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
choose_content_type(Req, State, ContentType, [{Accepted, Fun}|_Tail])
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
when Accepted =:= '*'; Accepted =:= ContentType ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
process_content_type(Req, State, Fun);
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
%% The special parameter '*' will always match any kind of content type
%% parameters.
%% Note that because it will always match, it should be the last of the
%% list for specific content type, otherwise it'll shadow the ones following.
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
choose_content_type(Req, State, {Type, SubType, Param},
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
[{{Type, SubType, AcceptedParam}, Fun}|_Tail])
when AcceptedParam =:= '*'; AcceptedParam =:= Param ->
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
process_content_type(Req, State, Fun);
choose_content_type(Req, State, ContentType, [_Any|Tail]) ->
choose_content_type(Req, State, ContentType, Tail).
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
Crash on failure, don't report errors 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.
2013-08-24 20:36:23 +02:00
process_content_type(Req, State=#state{method=Method, exists=Exists}, Fun) ->
try case call(Req, State, Fun) of
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState2} ->
Fix handler state change in cowboy_rest
2013-01-22 19:01:56 +07:00
terminate(Req2, State#state{handler_state=HandlerState2});
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
{true, Req2, HandlerState2} when Exists ->
State2 = State#state{handler_state=HandlerState2},
next(Req2, State2, fun has_resp_body/2);
Fix handler state change in cowboy_rest
2013-01-22 19:01:56 +07:00
{true, Req2, HandlerState2} ->
State2 = State#state{handler_state=HandlerState2},
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
next(Req2, State2, fun maybe_created/2);
Fix handler state change in cowboy_rest
2013-01-22 19:01:56 +07:00
{false, Req2, HandlerState2} ->
State2 = State#state{handler_state=HandlerState2},
Return 422 instead of 400 when AcceptResource returns false 422 is undefined for HTTP and interpreted as 400.
2014-06-30 17:49:36 +02:00
respond(Req2, State2, 400);
Make the return value of AcceptResource callback consistent
2013-05-16 15:14:11 +02:00
{{true, ResURL}, Req2, HandlerState2} when Method =:= <<"POST">> ->
Remove process_post, post_is_create, create_path, created_path callbacks 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.
2013-04-11 17:59:54 +02:00
State2 = State#state{handler_state=HandlerState2},
Req3 = cowboy_req:set_resp_header(
<<"location">>, ResURL, Req2),
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
if
Exists -> respond(Req3, State2, 303);
true -> respond(Req3, State2, 201)
end
Crash on failure, don't report errors 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.
2013-08-24 20:36:23 +02:00
end catch Class:Reason = {case_clause, no_call} ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Add '*' matcher for parameters 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.
2013-02-15 22:41:55 +07:00
end.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Properly send 201 on PUT requests when resource didn't exist Regardless of whether a location header has been set, as explained in the HTTP RFC.
2013-11-09 18:26:49 +01:00
%% If PUT was used then the resource has been created at the current URL.
%% Otherwise, if a location header has been set then the resource has been
%% created at a new URL. If not, send a 200 or 204 as expected from a
%% POST or PATCH request.
maybe_created(Req, State=#state{method= <<"PUT">>}) ->
respond(Req, State, 201);
Fix POST behavior in REST 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
2013-04-20 15:52:31 +02:00
maybe_created(Req, State) ->
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
case cowboy_req:has_resp_header(<<"location">>, Req) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
true -> respond(Req, State, 201);
false -> has_resp_body(Req, State)
end.
has_resp_body(Req, State) ->
Rename cowboy_http_req to cowboy_req
2012-08-27 13:28:57 +02:00
case cowboy_req:has_resp_body(Req) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
true -> multiple_choices(Req, State);
false -> respond(Req, State, 204)
end.
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
%% Set the Etag header if any for the response provided.
set_resp_body_etag(Req, State) ->
try set_resp_etag(Req, State) of
{Req2, State2} ->
set_resp_body_last_modified(Req2, State2)
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end.
%% Set the Last-Modified header if any for the response provided.
set_resp_body_last_modified(Req, State) ->
try last_modified(Req, State) of
{LastModified, Req2, State2} ->
case LastModified of
LastModified when is_atom(LastModified) ->
set_resp_body_expires(Req2, State2);
LastModified ->
LastModifiedBin = cowboy_clock:rfc1123(LastModified),
Req3 = cowboy_req:set_resp_header(
<<"last-modified">>, LastModifiedBin, Req2),
set_resp_body_expires(Req3, State2)
end
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end.
%% Set the Expires header if any for the response provided.
set_resp_body_expires(Req, State) ->
try set_resp_expires(Req, State) of
{Req2, State2} ->
set_resp_body(Req2, State2)
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end.
Add more documentation to the REST protocol handler
2011-12-08 20:16:04 +01:00
%% Set the response headers and call the callback found using
%% content_types_provided/2 to obtain the request body and add
%% it to the response.
Crash on failure, don't report errors 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.
2013-08-24 20:36:23 +02:00
set_resp_body(Req, State=#state{content_type_a={_, Callback}}) ->
try case call(Req, State, Callback) of
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState2} ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
terminate(Req2, State#state{handler_state=HandlerState2});
{Body, Req2, HandlerState2} ->
State2 = State#state{handler_state=HandlerState2},
Remaining Dialyzer fixes
2017-01-02 18:27:03 +01:00
Req3 = cowboy_req:set_resp_body(Body, Req2),
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
multiple_choices(Req3, State2)
Crash on failure, don't report errors 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.
2013-08-24 20:36:23 +02:00
end catch Class:Reason = {case_clause, no_call} ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Put the method in cowboy_rest's #state{}
2012-09-15 23:53:30 +02:00
end.
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
multiple_choices(Req, State) ->
expect(Req, State, multiple_choices, false, 200, 300).
%% Response utility functions.
set_resp_etag(Req, State) ->
{Etag, Req2, State2} = generate_etag(Req, State),
case Etag of
undefined ->
{Req2, State2};
Etag ->
Improve consistency of return types for cowboy_req API The signature of parse_header, body_qs, multipart_data and the set_resp_* functions has changed. See the cowboy_req module edoc for more details.
2012-09-16 03:51:07 +02:00
Req3 = cowboy_req:set_resp_header(
Convert headers to lowercase
2012-11-10 17:24:25 -05:00
<<"etag">>, encode_etag(Etag), Req2),
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
{Req3, State2}
end.
Tests and fixes for the generate_etag/2 callback 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.
2012-02-28 18:35:26 +01:00
-spec encode_etag({strong | weak, binary()}) -> iolist().
encode_etag({strong, Etag}) -> [$",Etag,$"];
encode_etag({weak, Etag}) -> ["W/\"",Etag,$"].
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
set_resp_expires(Req, State) ->
{Expires, Req2, State2} = expires(Req, State),
case Expires of
Expires when is_atom(Expires) ->
{Req2, State2};
Allow users to pass a raw binary() as the expires header.
2014-06-06 02:37:24 -04:00
Expires when is_binary(Expires) ->
Req3 = cowboy_req:set_resp_header(
Merge branch 'binary-expires' of git://github.com/NineFX/cowboy
2014-06-10 08:38:54 +02:00
<<"expires">>, Expires, Req2),
Allow users to pass a raw binary() as the expires header.
2014-06-06 02:37:24 -04:00
{Req3, State2};
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Expires ->
Remove the dependency on httpd_util Add the function cowboy_clock:rfc1123/1 that formats the given date to the RFC1123 format.
2012-12-03 15:57:27 +01:00
ExpiresBin = cowboy_clock:rfc1123(Expires),
Improve consistency of return types for cowboy_req API The signature of parse_header, body_qs, multipart_data and the set_resp_* functions has changed. See the cowboy_req module edoc for more details.
2012-09-16 03:51:07 +02:00
Req3 = cowboy_req:set_resp_header(
Remove the dependency on httpd_util Add the function cowboy_clock:rfc1123/1 that formats the given date to the RFC1123 format.
2012-12-03 15:57:27 +01:00
<<"expires">>, ExpiresBin, Req2),
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
{Req3, State2}
end.
%% Info retrieval. No logic.
generate_etag(Req, State=#state{etag=no_call}) ->
{undefined, Req, State};
generate_etag(Req, State=#state{etag=undefined}) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
case unsafe_call(Req, State, generate_etag) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
{undefined, Req, State#state{etag=no_call}};
Tests and fixes for the generate_etag/2 callback 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.
2012-02-28 18:35:26 +01:00
{Etag, Req2, HandlerState} when is_binary(Etag) ->
Use cowlib for parsing headers; remove cowboy_http
2015-02-04 16:18:28 +01:00
Etag2 = cow_http_hd:parse_etag(Etag),
Tests and fixes for the generate_etag/2 callback 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.
2012-02-28 18:35:26 +01:00
{Etag2, Req2, State#state{handler_state=HandlerState, etag=Etag2}};
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{Etag, Req2, HandlerState} ->
{Etag, Req2, State#state{handler_state=HandlerState, etag=Etag}}
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end;
generate_etag(Req, State=#state{etag=Etag}) ->
{Etag, Req, State}.
last_modified(Req, State=#state{last_modified=no_call}) ->
{undefined, Req, State};
last_modified(Req, State=#state{last_modified=undefined}) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
case unsafe_call(Req, State, last_modified) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
{undefined, Req, State#state{last_modified=no_call}};
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{LastModified, Req2, HandlerState} ->
{LastModified, Req2, State#state{handler_state=HandlerState,
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
last_modified=LastModified}}
end;
last_modified(Req, State=#state{last_modified=LastModified}) ->
{LastModified, Req, State}.
expires(Req, State=#state{expires=no_call}) ->
{undefined, Req, State};
expires(Req, State=#state{expires=undefined}) ->
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
case unsafe_call(Req, State, expires) of
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
no_call ->
{undefined, Req, State#state{expires=no_call}};
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{Expires, Req2, HandlerState} ->
{Expires, Req2, State#state{handler_state=HandlerState,
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
expires=Expires}}
end;
expires(Req, State=#state{expires=Expires}) ->
{Expires, Req, State}.
%% REST primitives.
expect(Req, State, Callback, Expected, OnTrue, OnFalse) ->
case call(Req, State, Callback) of
no_call ->
next(Req, State, OnTrue);
Rename 'halt' to 'stop' for better consistency 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.
2014-11-07 20:19:05 +02:00
{stop, Req2, HandlerState} ->
Add {halt, Req, State} return value to most REST callbacks Excluding generate_etag, last_modified, expires and variances.
2012-01-23 08:24:15 +01:00
terminate(Req2, State#state{handler_state=HandlerState});
Rename a lot of HandlerState2 variables to HandlerState
2012-01-23 08:11:29 +01:00
{Expected, Req2, HandlerState} ->
next(Req2, State#state{handler_state=HandlerState}, OnTrue);
{_Unexpected, Req2, HandlerState} ->
next(Req2, State#state{handler_state=HandlerState}, OnFalse)
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
end.
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
call(Req, State=#state{handler=Handler, handler_state=HandlerState},
Callback) ->
case erlang:function_exported(Handler, Callback, 2) of
true ->
try
Handler:Callback(Req, HandlerState)
catch Class:Reason ->
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
error_terminate(Req, State, Class, Reason)
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
end;
false ->
no_call
end.
unsafe_call(Req, #state{handler=Handler, handler_state=HandlerState},
Callback) ->
case erlang:function_exported(Handler, Callback, 2) of
true -> Handler:Callback(Req, HandlerState);
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
false -> no_call
end.
next(Req, State, Next) when is_function(Next) ->
Next(Req, State);
next(Req, State, StatusCode) when is_integer(StatusCode) ->
respond(Req, State, StatusCode).
respond(Req, State, StatusCode) ->
Breaking update of the cowboy_req interface 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.
2014-09-23 16:43:29 +03:00
terminate(cowboy_req:reply(StatusCode, Req), State).
Add experimental Webmachine based REST protocol support 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!
2011-12-05 22:53:59 +01:00
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
-spec error_terminate(cowboy_req:req(), #state{}, atom(), any()) -> no_return().
error_terminate(Req, #state{handler=Handler, handler_state=HandlerState}, Class, Reason) ->
Improve handler interface and documentation 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.
2014-09-30 20:12:13 +03:00
cowboy_handler:terminate({crash, Class, Reason}, Req, HandlerState, Handler),
Let the stream handler take care of crash handling and logging
2016-08-10 17:45:28 +02:00
erlang:raise(Class, Reason, erlang:get_stacktrace()).
Make sure rest_terminate is always called Also improves error reporting.
2013-02-09 16:45:30 +01:00
Remove the environment from cowboy_rest crash reports It only serves to pollute logs.
2016-06-06 17:30:13 +02:00
terminate(Req, #state{handler=Handler, handler_state=HandlerState}) ->
Improve handler interface and documentation 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.
2014-09-30 20:12:13 +03:00
Result = cowboy_handler:terminate(normal, Req, HandlerState, Handler),
Remove the environment from cowboy_rest crash reports It only serves to pollute logs.
2016-06-06 17:30:13 +02:00
{ok, Req, Result}.
Reference in a new issue Copy permalink