diff options
Diffstat (limited to 'archives/extend/2014-August.txt')
-rw-r--r-- | archives/extend/2014-August.txt | 2532 |
1 files changed, 2532 insertions, 0 deletions
diff --git a/archives/extend/2014-August.txt b/archives/extend/2014-August.txt new file mode 100644 index 00000000..4903378b --- /dev/null +++ b/archives/extend/2014-August.txt @@ -0,0 +1,2532 @@ +From samset at wanadoo.fr Mon Aug 4 18:39:26 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 18:39:26 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +Message-ID: <[email protected]> + +Hi, + +I?ve moved a working http server to https. +SSL handshaking is ok but i got the following Ranch error : + +[error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} + +call is + +curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? + + +dispatch is + +[{'_', [ + {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, + {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, + {"/mtagw", hck_mta, []} + ]}]). + + +Any clue ? + +Thanks + +sincerely + +Samir + + +From essen at ninenines.eu Mon Aug 4 18:49:32 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 18:49:32 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Surely there's something else that you're not showing there. For some +reason you got a list of segments in the error, and we haven't had that +for a very long time. Do you have an onrequest hook or middleware that +does weird things perhaps? + +On 08/04/2014 06:39 PM, Samir Sow wrote: +> Hi, +> +> I?ve moved a working http server to https. +> SSL handshaking is ok but i got the following Ranch error : +> +> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +> +> call is +> +> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +> +> +> dispatch is +> +> [{'_', [ +> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +> {"/mtagw", hck_mta, []} +> ]}]). +> +> +> Any clue ? +> +> Thanks +> +> sincerely +> +> Samir +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 19:50:36 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 19:50:36 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +I?m not sure i understand your question. + +I?ve only started a cowboy https server with a handler. +The http version was working fine. + +Sincerely + +Samir + +On 4 ao?t 2014, at 18:49, Lo?c Hoguin <essen at ninenines.eu> wrote: + +> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +> +> On 08/04/2014 06:39 PM, Samir Sow wrote: +>> Hi, +>> +>> I?ve moved a working http server to https. +>> SSL handshaking is ok but i got the following Ranch error : +>> +>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>> +>> call is +>> +>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>> +>> +>> dispatch is +>> +>> [{'_', [ +>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>> {"/mtagw", hck_mta, []} +>> ]}]). +>> +>> +>> Any clue ? +>> +>> Thanks +>> +>> sincerely +>> +>> Samir +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Mon Aug 4 19:59:57 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 19:59:57 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +I'm saying it can't be the only difference. + +On 08/04/2014 07:50 PM, Samir Sow wrote: +> I?m not sure i understand your question. +> +> I?ve only started a cowboy https server with a handler. +> The http version was working fine. +> +> Sincerely +> +> Samir +> +> On 4 ao?t 2014, at 18:49, Lo?c Hoguin <essen at ninenines.eu> wrote: +> +>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>> +>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>> Hi, +>>> +>>> I?ve moved a working http server to https. +>>> SSL handshaking is ok but i got the following Ranch error : +>>> +>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>> +>>> call is +>>> +>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>> +>>> +>>> dispatch is +>>> +>>> [{'_', [ +>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>> {"/mtagw", hck_mta, []} +>>> ]}]). +>>> +>>> +>>> Any clue ? +>>> +>>> Thanks +>>> +>>> sincerely +>>> +>>> Samir +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 20:16:06 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 20:16:06 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +I can assure you it?s the only one :) + +Samir + +On 4 ao?t 2014, at 19:59, Lo?c Hoguin <essen at ninenines.eu> wrote: + +> I'm saying it can't be the only difference. +> +> On 08/04/2014 07:50 PM, Samir Sow wrote: +>> I?m not sure i understand your question. +>> +>> I?ve only started a cowboy https server with a handler. +>> The http version was working fine. +>> +>> Sincerely +>> +>> Samir +>> +>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin <essen at ninenines.eu> wrote: +>> +>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>> +>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>> Hi, +>>>> +>>>> I?ve moved a working http server to https. +>>>> SSL handshaking is ok but i got the following Ranch error : +>>>> +>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>> +>>>> call is +>>>> +>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>> +>>>> +>>>> dispatch is +>>>> +>>>> [{'_', [ +>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>> {"/mtagw", hck_mta, []} +>>>> ]}]). +>>>> +>>>> +>>>> Any clue ? +>>>> +>>>> Thanks +>>>> +>>>> sincerely +>>>> +>>>> Samir +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Mon Aug 4 20:24:15 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 20:24:15 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Well I don't have any idea then. Cowboy is tested with http and https, +both with and without compression enabled. There's never been any +difference of the kind, the only difference is timing related. + +On 08/04/2014 08:16 PM, Samir Sow wrote: +> I can assure you it?s the only one :) +> +> Samir +> +> On 4 ao?t 2014, at 19:59, Lo?c Hoguin <essen at ninenines.eu> wrote: +> +>> I'm saying it can't be the only difference. +>> +>> On 08/04/2014 07:50 PM, Samir Sow wrote: +>>> I?m not sure i understand your question. +>>> +>>> I?ve only started a cowboy https server with a handler. +>>> The http version was working fine. +>>> +>>> Sincerely +>>> +>>> Samir +>>> +>>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin <essen at ninenines.eu> wrote: +>>> +>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>>> +>>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> I?ve moved a working http server to https. +>>>>> SSL handshaking is ok but i got the following Ranch error : +>>>>> +>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>>> +>>>>> call is +>>>>> +>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>>> +>>>>> +>>>>> dispatch is +>>>>> +>>>>> [{'_', [ +>>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>>> {"/mtagw", hck_mta, []} +>>>>> ]}]). +>>>>> +>>>>> +>>>>> Any clue ? +>>>>> +>>>>> Thanks +>>>>> +>>>>> sincerely +>>>>> +>>>>> Samir +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 20:25:25 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 20:25:25 +0200 +Subject: [99s-extend] Fwd: ranch dispatch error ver 1.0.0 +References: <[email protected]> +Message-ID: <[email protected]> + + +I found my mistake. + +I?ve a typo error - used a token instead of a function call in the dispatch object. +I apologize for the disturbance. + +Thank you. + +Sincerely + +Samir + +Begin forwarded message: + +> From: Samir Sow <samset at wanadoo.fr> +> Subject: Re: [99s-extend] ranch dispatch error ver 1.0.0 +> Date: 4 ao?t 2014 20:16:06 UTC+2 +> To: Lo?c Hoguin <essen at ninenines.eu> +> Cc: extend at lists.ninenines.eu +> +> I can assure you it?s the only one :) +> +> Samir +> +> On 4 ao?t 2014, at 19:59, Lo?c Hoguin <essen at ninenines.eu> wrote: +> +>> I'm saying it can't be the only difference. +>> +>> On 08/04/2014 07:50 PM, Samir Sow wrote: +>>> I?m not sure i understand your question. +>>> +>>> I?ve only started a cowboy https server with a handler. +>>> The http version was working fine. +>>> +>>> Sincerely +>>> +>>> Samir +>>> +>>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin <essen at ninenines.eu> wrote: +>>> +>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>>> +>>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> I?ve moved a working http server to https. +>>>>> SSL handshaking is ok but i got the following Ranch error : +>>>>> +>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>>> +>>>>> call is +>>>>> +>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>>> +>>>>> +>>>>> dispatch is +>>>>> +>>>>> [{'_', [ +>>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>>> {"/mtagw", hck_mta, []} +>>>>> ]}]). +>>>>> +>>>>> +>>>>> Any clue ? +>>>>> +>>>>> Thanks +>>>>> +>>>>> sincerely +>>>>> +>>>>> Samir +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 12:58:10 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 11:58:10 +0100 +Subject: [99s-extend] Broken links for REST flowcharts +Message-ID: <CA+dV7cSRzu0Mnz-JqzBnp2JqjVB=Cx5XswuBU-7BT7nZi9=1tQ@mail.gmail.com> + +Hi. + +The image links are broken for the REST flowcharts' guide, part of cowboy. + +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png +(for example) +should probably be +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png +according to the hierarchy here: +https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide + +Thanks. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/2c08b12c/attachment.html> + +From essen at ninenines.eu Tue Aug 5 13:19:12 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 13:19:12 +0200 +Subject: [99s-extend] Broken links for REST flowcharts +In-Reply-To: <CA+dV7cSRzu0Mnz-JqzBnp2JqjVB=Cx5XswuBU-7BT7nZi9=1tQ@mail.gmail.com> +References: <CA+dV7cSRzu0Mnz-JqzBnp2JqjVB=Cx5XswuBU-7BT7nZi9=1tQ@mail.gmail.com> +Message-ID: <[email protected]> + +Fixed, thanks. + +On 08/05/2014 12:58 PM, Paulo F. Oliveira wrote: +> Hi. +> +> The image links are broken for the REST flowcharts' guide, part of cowboy. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png +> (for example) +> should probably be +> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png +> according to the hierarchy here: +> https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide +> +> Thanks. +> +> - Paulo F. Oliveira +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Tue Aug 5 14:43:47 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 14:43:47 +0200 +Subject: [99s-extend] [ANN] Cowboy 1.0 +Message-ID: <[email protected]> + +Hello! + +Cowboy 1.0 has been released. + +Cowboy is a small and fast HTTP server for Erlang with support for +Webmachine-like REST, Websocket and more. + + https://github.com/ninenines/cowboy + +Cowboy is the work of more than 80 people. I would like to congratulate +everyone for the great work done so far. Thank you! + +Please see the CHANGELOG for details on what's changed. + + https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md + +This release marks the beginning of the 1.0.x branch which will contain +backward compatible fixes. This branch will be maintained at least until +Cowboy 2.0 gets released (longer if sponsors request it). It is highly +recommended that you follow this branch if you were following master +before, as master will receive backward incompatible changes starting +tomorrow. + +Cowboy is now fully documented. It has a user guide, a function +reference manual, and a wealth of examples. You can also install man +pages as explained in the README of the project. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/ + http://ninenines.eu/docs/en/cowboy/1.0/manual/ + https://github.com/ninenines/cowboy/tree/master/examples + +Following a discussion on the Erlang mailing lists the Getting Started +chapter was reworked and greatly simplified, in parts due to the +improvements made to erlang.mk. Feedback is of course always welcome. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ + +Starting tomorrow the master branch will receive backward incompatible +changes. Most of the planned changes are detailed in the ROADMAP. You +are welcome to suggest additional changes. + + https://github.com/ninenines/cowboy/blob/master/ROADMAP.md + +Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +18.0 comes out. There are no plans for a Cowboy 1.1 at this time, +although that may change in the coming months if there is interest in +new features. + +Ranch also got upgraded to 1.0, although there was no changes from the +previous release. + + https://github.com/ninenines/ranch + +Thanks to everyone who made this project what it is today! + +-- +Lo?c Hoguin +http://ninenines.eu + +From max.lapshin at gmail.com Tue Aug 5 15:33:27 2014 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Tue, 5 Aug 2014 17:33:27 +0400 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CAMxVRxAwOt8y83P7wSxhDiOVJe7OZn5AFqowRACBqCSCbf7Qhw@mail.gmail.com> + +Loic, it is very cool! + +Thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/a3d520b7/attachment.html> + +From gumm at sigma-star.com Tue Aug 5 17:56:25 2014 +From: gumm at sigma-star.com (Jesse Gumm) +Date: Tue, 5 Aug 2014 10:56:25 -0500 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CAPTXyXcOJic72bbd8VCANqGoJNRZ44-HOQgm=mwa-=jcUDnt4Q@mail.gmail.com> + +Congrats Loic! + +-- +Jesse Gumm +Owner, Sigma Star Systems +414.940.4866 || sigma-star.com || @jessegumm +On Aug 5, 2014 7:43 AM, "Lo?c Hoguin" <essen at ninenines.eu> wrote: + +> Hello! +> +> Cowboy 1.0 has been released. +> +> Cowboy is a small and fast HTTP server for Erlang with support for +> Webmachine-like REST, Websocket and more. +> +> https://github.com/ninenines/cowboy +> +> Cowboy is the work of more than 80 people. I would like to congratulate +> everyone for the great work done so far. Thank you! +> +> Please see the CHANGELOG for details on what's changed. +> +> https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md +> +> This release marks the beginning of the 1.0.x branch which will contain +> backward compatible fixes. This branch will be maintained at least until +> Cowboy 2.0 gets released (longer if sponsors request it). It is highly +> recommended that you follow this branch if you were following master +> before, as master will receive backward incompatible changes starting +> tomorrow. +> +> Cowboy is now fully documented. It has a user guide, a function reference +> manual, and a wealth of examples. You can also install man pages as +> explained in the README of the project. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/ +> http://ninenines.eu/docs/en/cowboy/1.0/manual/ +> https://github.com/ninenines/cowboy/tree/master/examples +> +> Following a discussion on the Erlang mailing lists the Getting Started +> chapter was reworked and greatly simplified, in parts due to the +> improvements made to erlang.mk. Feedback is of course always welcome. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ +> +> Starting tomorrow the master branch will receive backward incompatible +> changes. Most of the planned changes are detailed in the ROADMAP. You are +> welcome to suggest additional changes. +> +> https://github.com/ninenines/cowboy/blob/master/ROADMAP.md +> +> Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +> 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although +> that may change in the coming months if there is interest in new features. +> +> Ranch also got upgraded to 1.0, although there was no changes from the +> previous release. +> +> https://github.com/ninenines/ranch +> +> Thanks to everyone who made this project what it is today! +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/fb1bc75c/attachment.html> + +From lloyd at writersglen.com Tue Aug 5 19:34:33 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Tue, 5 Aug 2014 13:34:33 -0400 (EDT) +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Tip of the hat, Lo?c et. al. + +Outstanding and much appreciated work. + +Best to all, + +Lloyd + +-----Original Message----- +From: "Lo?c Hoguin" <essen at ninenines.eu> +Sent: Tuesday, August 5, 2014 8:43am +To: "Erlang" <erlang-questions at erlang.org>, Extend at lists.ninenines.eu +Subject: [erlang-questions] [ANN] Cowboy 1.0 + +Hello! + +Cowboy 1.0 has been released. + +Cowboy is a small and fast HTTP server for Erlang with support for +Webmachine-like REST, Websocket and more. + + https://github.com/ninenines/cowboy + +Cowboy is the work of more than 80 people. I would like to congratulate +everyone for the great work done so far. Thank you! + +Please see the CHANGELOG for details on what's changed. + + https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md + +This release marks the beginning of the 1.0.x branch which will contain +backward compatible fixes. This branch will be maintained at least until +Cowboy 2.0 gets released (longer if sponsors request it). It is highly +recommended that you follow this branch if you were following master +before, as master will receive backward incompatible changes starting +tomorrow. + +Cowboy is now fully documented. It has a user guide, a function +reference manual, and a wealth of examples. You can also install man +pages as explained in the README of the project. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/ + http://ninenines.eu/docs/en/cowboy/1.0/manual/ + https://github.com/ninenines/cowboy/tree/master/examples + +Following a discussion on the Erlang mailing lists the Getting Started +chapter was reworked and greatly simplified, in parts due to the +improvements made to erlang.mk. Feedback is of course always welcome. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ + +Starting tomorrow the master branch will receive backward incompatible +changes. Most of the planned changes are detailed in the ROADMAP. You +are welcome to suggest additional changes. + + https://github.com/ninenines/cowboy/blob/master/ROADMAP.md + +Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +18.0 comes out. There are no plans for a Cowboy 1.1 at this time, +although that may change in the coming months if there is interest in +new features. + +Ranch also got upgraded to 1.0, although there was no changes from the +previous release. + + https://github.com/ninenines/ranch + +Thanks to everyone who made this project what it is today! + +-- +Lo?c Hoguin +http://ninenines.eu +_______________________________________________ +erlang-questions mailing list +erlang-questions at erlang.org +http://erlang.org/mailman/listinfo/erlang-questions + + + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 22:33:17 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 21:33:17 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <CAMuJbHgMSNLnCuf5x2+Nx1zUFhHy3=0rTGtLNbLJ=FfDU=tjfQ@mail.gmail.com> +References: <[email protected]> + <CAMxVRxAwOt8y83P7wSxhDiOVJe7OZn5AFqowRACBqCSCbf7Qhw@mail.gmail.com> + <CAMuJbHgMSNLnCuf5x2+Nx1zUFhHy3=0rTGtLNbLJ=FfDU=tjfQ@mail.gmail.com> +Message-ID: <CA+dV7cRYs3nfweJjUYLh-cCuuxmFbngoFUdDjoYgYwkky3LFNQ@mail.gmail.com> + +Hi, Federico. + +Check this out for the "why" regarding your question: +https://github.com/ninenines/cowboy/issues/715 + +It's one of the reasons (I haven't detected others yet) stopping me from +moving to 1.0, unfortunately (I have some projects depending on these +status codes already), but as soon as I have some time and look at all the +_major_ differences between 0.9.0 and 1.0 I think I'll make the move. For +the time being, I have found no issues with the REST part of cowboy (the +one I use). + +Thank you, Lo?c et all for the effort and for keeping it open source. + +Regards. + +- Paulo F. Oliveira + + +On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com> wrote: + +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 instead of +> 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com> +> wrote: +> +>> Loic, it is very cool! +>> +>> Thanks. +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +> +> +> -- +> http://federicocarrone.com/ +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/f3705f7b/attachment.html> + +From essen at ninenines.eu Tue Aug 5 22:55:34 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 22:55:34 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <CA+dV7cRYs3nfweJjUYLh-cCuuxmFbngoFUdDjoYgYwkky3LFNQ@mail.gmail.com> +References: <[email protected]> + <CAMxVRxAwOt8y83P7wSxhDiOVJe7OZn5AFqowRACBqCSCbf7Qhw@mail.gmail.com> + <CAMuJbHgMSNLnCuf5x2+Nx1zUFhHy3=0rTGtLNbLJ=FfDU=tjfQ@mail.gmail.com> + <CA+dV7cRYs3nfweJjUYLh-cCuuxmFbngoFUdDjoYgYwkky3LFNQ@mail.gmail.com> +Message-ID: <[email protected]> + +You can easily send 422 and return halt instead of returning false if +you need to keep that, it'll just be 2 lines instead of 1. :) + +On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> Hi, Federico. +> +> Check this out for the "why" regarding your question: +> https://github.com/ninenines/cowboy/issues/715 +> +> It's one of the reasons (I haven't detected others yet) stopping me from +> moving to 1.0, unfortunately (I have some projects depending on these +> status codes already), but as soon as I have some time and look at all +> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +> move. For the time being, I have found no issues with the REST part of +> cowboy (the one I use). +> +> Thank you, Lo?c et all for the effort and for keeping it open source. +> +> Regards. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com +> <mailto:federico.carrone at gmail.com>> wrote: +> +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 +> instead of 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com +> <mailto:max.lapshin at gmail.com>> wrote: +> +> Loic, it is very cool! +> +> Thanks. +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +> +> +> -- +> http://federicocarrone.com/ +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 23:01:38 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 22:01:38 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAMxVRxAwOt8y83P7wSxhDiOVJe7OZn5AFqowRACBqCSCbf7Qhw@mail.gmail.com> + <CAMuJbHgMSNLnCuf5x2+Nx1zUFhHy3=0rTGtLNbLJ=FfDU=tjfQ@mail.gmail.com> + <CA+dV7cRYs3nfweJjUYLh-cCuuxmFbngoFUdDjoYgYwkky3LFNQ@mail.gmail.com> +Message-ID: <CA+dV7cRNHiuZcJzc+x3=eVuEsty3-8pE_2XqBOpVdg4MSch_AA@mail.gmail.com> + +Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only +important difference I should be aware of, then? I haven't written any real +tests, for the time being, to guarantee backward compatibility for +dependants... + +In any case, I'm thinking about updating the dependencies in the future (I +own one of them and the other one is an internal project, for the time +being). + +Thanks for the tip. + +Cheers. + +- Paulo F. Oliveira + + +On 5 August 2014 21:55, Lo?c Hoguin <essen at ninenines.eu> wrote: + +> You can easily send 422 and return halt instead of returning false if you +> need to keep that, it'll just be 2 lines instead of 1. :) +> +> On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> +>> Hi, Federico. +>> +>> Check this out for the "why" regarding your question: +>> https://github.com/ninenines/cowboy/issues/715 +>> +>> It's one of the reasons (I haven't detected others yet) stopping me from +>> moving to 1.0, unfortunately (I have some projects depending on these +>> status codes already), but as soon as I have some time and look at all +>> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +>> move. For the time being, I have found no issues with the REST part of +>> cowboy (the one I use). +>> +>> Thank you, Lo?c et all for the effort and for keeping it open source. +>> +>> Regards. +>> +>> - Paulo F. Oliveira +>> +>> +>> On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com +>> <mailto:federico.carrone at gmail.com>> wrote: +>> +>> Congratulations Loic. I really love cowboy. +>> +>> I got only one question: Why did you change the reply with 400 +>> instead of 422 in cowboy_rest for unprocessable entities? +>> +>> Regards, +>> Federico. +>> +>> +>> +>> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com +>> <mailto:max.lapshin at gmail.com>> wrote: +>> +>> Loic, it is very cool! +>> +>> Thanks. +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +>> +>> +>> -- +>> http://federicocarrone.com/ +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/34528764/attachment.html> + +From essen at ninenines.eu Tue Aug 5 23:06:19 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 23:06:19 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <CA+dV7cRNHiuZcJzc+x3=eVuEsty3-8pE_2XqBOpVdg4MSch_AA@mail.gmail.com> +References: <[email protected]> <CAMxVRxAwOt8y83P7wSxhDiOVJe7OZn5AFqowRACBqCSCbf7Qhw@mail.gmail.com> <CAMuJbHgMSNLnCuf5x2+Nx1zUFhHy3=0rTGtLNbLJ=FfDU=tjfQ@mail.gmail.com> <CA+dV7cRYs3nfweJjUYLh-cCuuxmFbngoFUdDjoYgYwkky3LFNQ@mail.gmail.com> <[email protected]> + <CA+dV7cRNHiuZcJzc+x3=eVuEsty3-8pE_2XqBOpVdg4MSch_AA@mail.gmail.com> +Message-ID: <[email protected]> + +If you were already at the previous version (0.10) then that plus a 400 +instead of 500 when header parsing fails are pretty much the only changes. + +There's some more if you were at 0.9, mostly the body reading interface +changed to prevent annoying timeout issues. + +On 08/05/2014 11:01 PM, Paulo F. Oliveira wrote: +> Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only +> important difference I should be aware of, then? I haven't written any +> real tests, for the time being, to guarantee backward compatibility for +> dependants... +> +> In any case, I'm thinking about updating the dependencies in the future +> (I own one of them and the other one is an internal project, for the +> time being). +> +> Thanks for the tip. +> +> Cheers. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 21:55, Lo?c Hoguin <essen at ninenines.eu +> <mailto:essen at ninenines.eu>> wrote: +> +> You can easily send 422 and return halt instead of returning false +> if you need to keep that, it'll just be 2 lines instead of 1. :) +> +> On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> +> Hi, Federico. +> +> Check this out for the "why" regarding your question: +> https://github.com/ninenines/__cowboy/issues/715 +> <https://github.com/ninenines/cowboy/issues/715> +> +> It's one of the reasons (I haven't detected others yet) stopping +> me from +> moving to 1.0, unfortunately (I have some projects depending on +> these +> status codes already), but as soon as I have some time and look +> at all +> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +> move. For the time being, I have found no issues with the REST +> part of +> cowboy (the one I use). +> +> Thank you, Lo?c et all for the effort and for keeping it open +> source. +> +> Regards. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 15:18, Federico Carrone +> <federico.carrone at gmail.com <mailto:federico.carrone at gmail.com> +> <mailto:federico.carrone at __gmail.com +> <mailto:federico.carrone at gmail.com>>> wrote: +> +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 +> instead of 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin +> <max.lapshin at gmail.com <mailto:max.lapshin at gmail.com> +> <mailto:max.lapshin at gmail.com +> <mailto:max.lapshin at gmail.com>>__> wrote: +> +> Loic, it is very cool! +> +> Thanks. +> +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +> <mailto:erlang-questions at __erlang.org +> <mailto:erlang-questions at erlang.org>> +> http://erlang.org/mailman/__listinfo/erlang-questions +> <http://erlang.org/mailman/listinfo/erlang-questions> +> +> +> +> +> -- +> http://federicocarrone.com/ +> +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org> +> <mailto:erlang-questions at __erlang.org +> <mailto:erlang-questions at erlang.org>> +> http://erlang.org/mailman/__listinfo/erlang-questions +> <http://erlang.org/mailman/listinfo/erlang-questions> +> +> +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu> +> https://lists.ninenines.eu/__listinfo/extend +> <https://lists.ninenines.eu/listinfo/extend> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From michael.wittig at tullius-walden.com Wed Aug 13 11:17:51 2014 +From: michael.wittig at tullius-walden.com (Michael Wittig) +Date: Wed, 13 Aug 2014 11:17:51 +0200 +Subject: [99s-extend] eunit suppoort in erlang.mk? +Message-ID: <CAAgJJDuQ4RLXMU7YB3CK6ZvE7RcOyGO1-Xwa4736r1HYyhDOmQ@mail.gmail.com> + +hi, + +is it possible to run eunit tests when executing make tests? +I have my tests directly in the modules (e.g. xyz_server) + +Regards, + +Michael +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140813/7903a29a/attachment.html> + +From chaehb at gmail.com Thu Aug 14 03:20:05 2014 +From: chaehb at gmail.com (chaehb) +Date: Thu, 14 Aug 2014 10:20:05 +0900 +Subject: [99s-extend] couldn't quit in Erlang 17.1 +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + + +On 2014. 7. 27., at ?? 6:25, Lo?c Hoguin <essen at ninenines.eu> wrote: + +> Does it happen with ssl_hello_world? +> +> On 07/26/2014 09:06 AM, chaehb wrote: +>> Hi, everybody. +>> +>> After Erlang updated to 17.1, +>> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages.. +>> +>> (after ok signal printed) +>> +>> ?... +>> =ERROR REPORT==== 26-Jul-2014::15:23:33 === +>> Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +>> ?. +>> +>> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments. +>> +>> This is only appeared when I only use ssl(https). +>> But when use only http with same dispatch rules, cowboy normally quitted. +>> + +I?ve try to do more tests with ssl_hello_world in cowboy(v1.0) and various Erlang/OTP versions. + +If ErlangOTP < 17.0, http/https works fine. +If ErlangOTP >= 17.1(17.1.x,17.2 in github), http works fine but with https the same errors appeared. + +***** +When I edited ranch_accepter.erl > line 40 + {error, Reason} when Reason =/= closed -> + to + {error, Reason} -> +, +https work and app was normally quitted. + +When I printed, Reason == closed. + + +From lists at tuli.pe Thu Aug 14 17:44:25 2014 +From: lists at tuli.pe (Camille Troillard) +Date: Thu, 14 Aug 2014 17:44:25 +0200 +Subject: [99s-extend] cowboy_rest and response headers +Message-ID: <[email protected]> + +Hello, + +I would like to set a Content-Range header in the response of a HEAD request. +Can I do that within the context of a cowboy_rest handler? +Ideally, I wish to let cowboy_rest reply and just specify this additional header. + + +Best, +Camille +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140814/64f862ef/attachment.html> + +From essen at ninenines.eu Thu Aug 14 17:50:09 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 14 Aug 2014 17:50:09 +0200 +Subject: [99s-extend] cowboy_rest and response headers +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Use cowboy_req:set_resp_header and return the Req this function gives you. + +On 08/14/2014 05:44 PM, Camille Troillard wrote: +> Hello, +> +> I would like to set a Content-Range header in the response of a HEAD +> request. +> Can I do that within the context of a cowboy_rest handler? +> Ideally, I wish to let cowboy_rest reply and just specify this +> additional header. +> +> +> Best, +> Camille +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Sun Aug 24 01:58:12 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 01:58:12 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +Message-ID: <[email protected]> + +Hi all, + +1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +have a small crash. + +Here is my code: + +https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 + +Could you tell me if I correctly use cowboy_rest for the PUT verb? I +have seen is_conflict/2, but I don't know how to use it. + +2. I would like to change the response code, but I get the error. Is it +possible? + +Thank you. + +Regards, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From daniel.goertzen at gmail.com Sun Aug 24 02:16:02 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Sat, 23 Aug 2014 19:16:02 -0500 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CAJCf5RxAZR2jx3Bf-XmYMPYs-i4rk8-Ba4xYqMWv=AjM3P33SQ@mail.gmail.com> + +You should implement the resource_exists() callback; this will let the rest +module pick a 200 vs 201. If the db name was incorrect, I think you are +just supposed to return false from the put callback. I can't remember the +http code for that case. + +Regards, +Dan. + + +On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel <stephane at wirtel.be> wrote: + +> Hi all, +> +> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have +> a small crash. +> +> Here is my code: +> +> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +> +> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +> seen is_conflict/2, but I don't know how to use it. +> +> 2. I would like to change the response code, but I get the error. Is it +> possible? +> +> Thank you. +> +> Regards, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140823/51e1d345/attachment.html> + +From stephane at wirtel.be Sun Aug 24 02:22:22 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 02:22:22 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <CAJCf5RxAZR2jx3Bf-XmYMPYs-i4rk8-Ba4xYqMWv=AjM3P33SQ@mail.gmail.com> +References: <[email protected]> + <CAJCf5RxAZR2jx3Bf-XmYMPYs-i4rk8-Ba4xYqMWv=AjM3P33SQ@mail.gmail.com> +Message-ID: <[email protected]> + +resource_exists is used by POST +is_conflict is used by PUT (from the code) +but in the case where my database already exists, I need to return 412 +and not 409. + +and I know I don't respect the default value returned by Cowboy_rest. + +On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: + +> You should implement the resource_exists() callback; this will let the +> rest +> module pick a 200 vs 201. If the db name was incorrect, I think you +> are +> just supposed to return false from the put callback. I can't remember +> the +> http code for that case. +> +> Regards, +> Dan. +> +> +> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel <stephane at wirtel.be> +> wrote: +> +>> Hi all, +>> +>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +>> have +>> a small crash. +>> +>> Here is my code: +>> +>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>> +>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I +>> have +>> seen is_conflict/2, but I don't know how to use it. +>> +>> 2. I would like to change the response code, but I get the error. Is +>> it +>> possible? +>> +>> Thank you. +>> +>> Regards, +>> +>> Stephane +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From edgurgel at gmail.com Sun Aug 24 02:25:54 2014 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Sun, 24 Aug 2014 12:25:54 +1200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAJCf5RxAZR2jx3Bf-XmYMPYs-i4rk8-Ba4xYqMWv=AjM3P33SQ@mail.gmail.com> +Message-ID: <CAKAMJXhPm0vZdTrhW3Zg=zyowQzc0AczhptyTAVyX404pvc3XA@mail.gmail.com> + +I think you can always halt the processing and do the reply by yourself: + +{ok, Req2} = cowboy_req:reply(412, Req), +{halt, Req2, State}. + + +On Sun, Aug 24, 2014 at 12:22 PM, St?phane Wirtel <stephane at wirtel.be> +wrote: + +> resource_exists is used by POST +> is_conflict is used by PUT (from the code) +> but in the case where my database already exists, I need to return 412 and +> not 409. +> +> and I know I don't respect the default value returned by Cowboy_rest. +> +> +> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: +> +> You should implement the resource_exists() callback; this will let the +>> rest +>> module pick a 200 vs 201. If the db name was incorrect, I think you are +>> just supposed to return false from the put callback. I can't remember the +>> http code for that case. +>> +>> Regards, +>> Dan. +>> +>> +>> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel <stephane at wirtel.be> +>> wrote: +>> +>> Hi all, +>>> +>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +>>> have +>>> a small crash. +>>> +>>> Here is my code: +>>> +>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>>> +>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +>>> seen is_conflict/2, but I don't know how to use it. +>>> +>>> 2. I would like to change the response code, but I get the error. Is it +>>> possible? +>>> +>>> Thank you. +>>> +>>> Regards, +>>> +>>> Stephane +>>> +>>> -- +>>> St?phane Wirtel - http://wirtel.be - @matrixise +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>>> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + + + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140824/89d3a7f6/attachment.html> + +From stephane at wirtel.be Sun Aug 24 02:52:58 2014 +From: stephane at wirtel.be (Stephane Wirtel) +Date: Sun, 24 Aug 2014 02:52:58 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <CAKAMJXhPm0vZdTrhW3Zg=zyowQzc0AczhptyTAVyX404pvc3XA@mail.gmail.com> +References: <[email protected]> + <CAJCf5RxAZR2jx3Bf-XmYMPYs-i4rk8-Ba4xYqMWv=AjM3P33SQ@mail.gmail.com> + <CAKAMJXhPm0vZdTrhW3Zg=zyowQzc0AczhptyTAVyX404pvc3XA@mail.gmail.com> +Message-ID: <[email protected]> + +Ok I will try asap, thanks + +> On 24 ao?t 2014, at 02:25 AM, Eduardo Gurgel <edgurgel at gmail.com> wrote: +> +> I think you can always halt the processing and do the reply by yourself: +> +> {ok, Req2} = cowboy_req:reply(412, Req), +> {halt, Req2, State}. +> +> +>> On Sun, Aug 24, 2014 at 12:22 PM, St?phane Wirtel <stephane at wirtel.be> wrote: +>> resource_exists is used by POST +>> is_conflict is used by PUT (from the code) +>> but in the case where my database already exists, I need to return 412 and not 409. +>> +>> and I know I don't respect the default value returned by Cowboy_rest. +>> +>> +>> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: +>> +>>> You should implement the resource_exists() callback; this will let the rest +>>> module pick a 200 vs 201. If the db name was incorrect, I think you are +>>> just supposed to return false from the put callback. I can't remember the +>>> http code for that case. +>>> +>>> Regards, +>>> Dan. +>>> +>>> +>>> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel <stephane at wirtel.be> wrote: +>>> +>>>> Hi all, +>>>> +>>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have +>>>> a small crash. +>>>> +>>>> Here is my code: +>>>> +>>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>>>> +>>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +>>>> seen is_conflict/2, but I don't know how to use it. +>>>> +>>>> 2. I would like to change the response code, but I get the error. Is it +>>>> possible? +>>>> +>>>> Thank you. +>>>> +>>>> Regards, +>>>> +>>>> Stephane +>>>> +>>>> -- +>>>> St?phane Wirtel - http://wirtel.be - @matrixise +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> +> +> +> -- +> Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140824/f35e1e51/attachment.html> + +From stephane at wirtel.be Sun Aug 24 11:54:58 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 11:54:58 +0200 +Subject: [99s-extend] Full example of cowboy_rest? +Message-ID: <[email protected]> + +Hi all, + +Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, +PUT and DELETE ? + +POST will use resource_exists and allow_missing_post +PUT will use is_conflict +DELETE delete_resource, etc... + +Currently, I started with the example with put_json and get_json and in +the functions, I fetch the Method and I use the pattern matching with +the Method, but I think it's not the right solution. + +What are the best practices? + +The examples in the repository of cowboy don't cover all the +possibilities of a simple rest api with these verbs. + +Thanks in advance, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From paulo.ferraz.oliveira at gmail.com Tue Aug 26 01:11:44 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 26 Aug 2014 00:11:44 +0100 +Subject: [99s-extend] Full example of cowboy_rest? +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CA+dV7cQXP3wEq5bn=3qWQ2EKuR39WZsRHCS+4Q1wgvLgDucjng@mail.gmail.com> + +Hello, St?phane. + +On 24 August 2014 10:54, St?phane Wirtel <stephane at wirtel.be> wrote: +> +> Hi all, +> +> Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, PUT and DELETE ? + +AFAIK, from the official examples, the correct answer is "no", there +is no "complete" example (does it even make sense to have one?). + +On the other hand, I've been using Cowboy for a couple of months now, +and find these docs (REST flowcharts - +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/) to be +very useful, and they might also help you. You should find the time to +read the complete REST guide/manual as a lot of useful information can +be found there and a very nice effort was put into not wasting words +and going straight to the point. + +... + +> What are the best practices? + +For what specifically? + +> The examples in the repository of cowboy don't cover all the possibilities of a simple rest api with these verbs. + +That is a fact. I, for one, tend to have a _template_ source code file +from where I get the functions that I need (only not to have to write +2/3 lines of code every time), and that I "chain" looking at the +flowcharts. [I also have a lib for JSON parsing and validating, query +string validation, etc...] This might not always be very easy (to +"chain" it all together, but it shouldn't be that hard either"), but +my approach is usually "OK, so I want a route to have GET, PUT and +DELETE... what are the related methods that I'll most probably +require? resource_exists (serves all methods), is_conflict (serves +PUT), delete_resource (serves DELETE), delete_completed (serves +DELETE)" and then I think about replying with a body or not (in the +case of GET there will almost always be a body, in the case of PUT +your method call might result in a 204 and in the case of DELETE there +may or not be a body). I then code the methods, test the API, checking +that the codes I get make sense (404, 200, 409, 204, 202, ... +depending on the conditions I want set) and then slightly document +this for the users of the API (if the API is complicated and requires +a lot of documentation there might be something wrong with it). For +documentation purposes you can either go with a "[VERB] route +accepts...?..., serves...?..., and the result codes are...?..." simple +doc or something more elaborate like +https://helloreverb.com/developers/swagger. + +Hope it helps. + +- Paulo F. Oliveira + +> +> Thanks in advance, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +From stephane at wirtel.be Tue Aug 26 23:59:50 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Tue, 26 Aug 2014 23:59:50 +0200 +Subject: [99s-extend] cowboy_rest and delete_completed and response +Message-ID: <[email protected]> + +Hi all, + +I work with two content-types (json, msgpack). + +In the DELETE verb, I need to return an object and in this case, I work +on delete_resource/2 and delete_completed/2. +The problem is, how can I return a body in function of the content-type? +because after delete_completed, there is a call to the +cowboy_rest:has_resp_body function and I need to set the body of the +response. + +delete_completed(Req, State) -> + Body = Json or MsgPack ? <-- Which content ? + + Req2 = cowboy_req:set_resp_body(Body, Req), + {true, Req2, State}. + +Ok, but in this case, what's the reason of content_types_provided/2 and +content_types_accepted/2 ? + +Thank you, + +Stephane + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 00:03:45 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 01:03:45 +0300 +Subject: [99s-extend] cowboy_rest and delete_completed and response +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Call cowboy_req:meta(media_type, Req) to retrieve it. + +On 08/27/2014 12:59 AM, St?phane Wirtel wrote: +> Hi all, +> +> I work with two content-types (json, msgpack). +> +> In the DELETE verb, I need to return an object and in this case, I work +> on delete_resource/2 and delete_completed/2. +> The problem is, how can I return a body in function of the content-type? +> because after delete_completed, there is a call to the +> cowboy_rest:has_resp_body function and I need to set the body of the +> response. +> +> delete_completed(Req, State) -> +> Body = Json or MsgPack ? <-- Which content ? +> +> Req2 = cowboy_req:set_resp_body(Body, Req), +> {true, Req2, State}. +> +> Ok, but in this case, what's the reason of content_types_provided/2 and +> content_types_accepted/2 ? +> +> Thank you, +> +> Stephane +> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 00:12:00 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 00:12:00 +0200 +Subject: [99s-extend] cowboy_rest and delete_completed and response +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +What's the purpose of the callbacks in content_types_accepted and +content_types_provided? + +I prefer set the response in the State to the callbacks and they convert +it to the right format. + +Example: + +delete_completed(Req, State) -> + Response = [{<<"ok">>, <<"dbname">>}], + {true, Req, State#state{response=Response}}. + +get_json(Req, #{response=Response}=State) -> + Body = jsx:encode(Response), + {Body, Req, State}. + +get_msgpack(Req, #{response=Response}=State) -> + Body = msgpack:pack(Response, [{format, jsx}], + {Body, Req, State}. + + + +On 27 Aug 2014, at 0:03, Lo?c Hoguin wrote: + +> Call cowboy_req:meta(media_type, Req) to retrieve it. +> +> On 08/27/2014 12:59 AM, St?phane Wirtel wrote: +>> Hi all, +>> +>> I work with two content-types (json, msgpack). +>> +>> In the DELETE verb, I need to return an object and in this case, I +>> work +>> on delete_resource/2 and delete_completed/2. +>> The problem is, how can I return a body in function of the +>> content-type? +>> because after delete_completed, there is a call to the +>> cowboy_rest:has_resp_body function and I need to set the body of the +>> response. +>> +>> delete_completed(Req, State) -> +>> Body = Json or MsgPack ? <-- Which content ? +>> +>> Req2 = cowboy_req:set_resp_body(Body, Req), +>> {true, Req2, State}. +>> +>> Ok, but in this case, what's the reason of content_types_provided/2 +>> and +>> content_types_accepted/2 ? +>> +>> Thank you, +>> +>> Stephane +>> +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From stephane at wirtel.be Wed Aug 27 11:29:46 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 11:29:46 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest handler. +Message-ID: <[email protected]> + +Hi all, + +This night, I wrote an example because I wanted to show you my work. + +I have one handler for the concept of collections (in this case, tasks). + +In this handler, I want these following methods: + +POST /:collection +GET /:collection +DELETE /:collection +PUT /:collection +HEAD /:collection + +:collection is a string, example: /tasks1 + +HEAD /:collection (/tasks1) +StatusCode: + * 200 ok + * 404 not found + +GET /:collection (/tasks1) +Gets information about the collection +StatusCode: + * 200 ok + * 404 not found + +PUT /:collection (/tasks1) +Create a new collection of tasks +Status_Code: + * 201 created + Response: an object, in msgpack or json and I need to had a location +header + * 412 precondition failed, the collection name already exists + Response: an object, in msgpack or json with the error (already exists) + +POST /:collection (/tasks1) +Add a new item in the collection, a new task +StatusCode: + * 201 created + * 202 accepted + * 404 not found (error in the collection name) +Response: need to add a location header and return an object in msgpack +or json. + +DELETE /:collection (/tasks1) +Delete all the tasks +Status_Code: + * 200 ok. + * 404 not found +In the case of 200, we need to return an object in msgpack or json. + + +I provided a code and If you can help me, because I think cowboy_rest is +a good solution, but I also think I will have some problems with my +service. + +Examples: +* delete_completed, I need to write the serialisation in the +delete_completed function and not with the help of the defined callbacks +of content_types_provided. +* for PUT, I need to return a location header, should I add it in the +is_conflict +function? +* for PUT, how I have a 201? I have read the rest_flowchart and I need +to specify the location header ok, but where? in the is_conflict +function? + +So, do you have time to help me, because with this example, I can +propose it to the cowboy repository. +https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl + +You can propose your PR, comments or remarks, but I would like to use +cowboy_rest. + +Regards, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 12:03:41 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 13:03:41 +0300 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Hey, + +On 08/27/2014 12:29 PM, St?phane Wirtel wrote: +> Hi all, +> +> This night, I wrote an example because I wanted to show you my work. +> +> I have one handler for the concept of collections (in this case, tasks). +> +> In this handler, I want these following methods: +> +> POST /:collection +> GET /:collection +> DELETE /:collection +> PUT /:collection +> HEAD /:collection +> +> :collection is a string, example: /tasks1 +> +> HEAD /:collection (/tasks1) +> StatusCode: +> * 200 ok +> * 404 not found +> +> GET /:collection (/tasks1) +> Gets information about the collection +> StatusCode: +> * 200 ok +> * 404 not found +> +> PUT /:collection (/tasks1) +> Create a new collection of tasks +> Status_Code: +> * 201 created +> Response: an object, in msgpack or json and I need to had a +> location header +> * 412 precondition failed, the collection name already exists +> Response: an object, in msgpack or json with the error (already +> exists) +> +> POST /:collection (/tasks1) +> Add a new item in the collection, a new task +> StatusCode: +> * 201 created +> * 202 accepted +> * 404 not found (error in the collection name) +> Response: need to add a location header and return an object in msgpack +> or json. +> +> DELETE /:collection (/tasks1) +> Delete all the tasks +> Status_Code: +> * 200 ok. +> * 404 not found +> In the case of 200, we need to return an object in msgpack or json. +> +> +> I provided a code and If you can help me, because I think cowboy_rest is +> a good solution, but I also think I will have some problems with my +> service. +> +> Examples: +> * delete_completed, I need to write the serialisation in the +> delete_completed function and not with the help of the defined callbacks +> of content_types_provided. + +What's the problem? The callbacks you set in content_types_provided are +there to provide the *resource*. If you set a body in response to the +DELETE method you are not sending the resource but information about the +result of the operation. + +> * for PUT, I need to return a location header, should I add it in the +> is_conflict +> function? + +I would say in the callback you set in content_types_accepted. But... + +> * for PUT, how I have a 201? I have read the rest_flowchart and I need +> to specify the location header ok, but where? in the is_conflict function? + +Why do you need a 201? If you PUT a collection to /:collection then this +is already the location of the collection. I am not sure what you are +trying to do there exactly? + +> So, do you have time to help me, because with this example, I can +> propose it to the cowboy repository. +> https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl +> +> +> You can propose your PR, comments or remarks, but I would like to use +> cowboy_rest. +> +> Regards, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 12:35:33 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 12:35:33 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +On 27 Aug 2014, at 12:03, Lo?c Hoguin wrote: + +> Hey, +> +> On 08/27/2014 12:29 PM, St?phane Wirtel wrote: +>> Hi all, +>> +>> This night, I wrote an example because I wanted to show you my work. +>> +>> I have one handler for the concept of collections (in this case, +>> tasks). +>> +>> In this handler, I want these following methods: +>> +>> POST /:collection +>> GET /:collection +>> DELETE /:collection +>> PUT /:collection +>> HEAD /:collection +>> +>> :collection is a string, example: /tasks1 +>> +>> HEAD /:collection (/tasks1) +>> StatusCode: +>> * 200 ok +>> * 404 not found +>> +>> GET /:collection (/tasks1) +>> Gets information about the collection +>> StatusCode: +>> * 200 ok +>> * 404 not found +>> +>> PUT /:collection (/tasks1) +>> Create a new collection of tasks +>> Status_Code: +>> * 201 created +>> Response: an object, in msgpack or json and I need to had a +>> location header +>> * 412 precondition failed, the collection name already exists +>> Response: an object, in msgpack or json with the error (already +>> exists) +>> +>> POST /:collection (/tasks1) +>> Add a new item in the collection, a new task +>> StatusCode: +>> * 201 created +>> * 202 accepted +>> * 404 not found (error in the collection name) +>> Response: need to add a location header and return an object in +>> msgpack +>> or json. +>> +>> DELETE /:collection (/tasks1) +>> Delete all the tasks +>> Status_Code: +>> * 200 ok. +>> * 404 not found +>> In the case of 200, we need to return an object in msgpack or json. +>> +>> +>> I provided a code and If you can help me, because I think cowboy_rest +>> is +>> a good solution, but I also think I will have some problems with my +>> service. +>> +>> Examples: +>> * delete_completed, I need to write the serialisation in the +>> delete_completed function and not with the help of the defined +>> callbacks +>> of content_types_provided. +> +> What's the problem? The callbacks you set in content_types_provided +> are there to provide the *resource*. If you set a body in response to +> the DELETE method you are not sending the resource but information +> about the result of the operation. +Ok, in this case, I understand. thanks +> +>> * for PUT, I need to return a location header, should I add it in the +>> is_conflict +>> function? +> +> I would say in the callback you set in content_types_accepted. But... +Works fine in the is_conflict function. +> +>> * for PUT, how I have a 201? I have read the rest_flowchart and I +>> need +>> to specify the location header ok, but where? in the is_conflict +>> function? +> +> Why do you need a 201? If you PUT a collection to /:collection then +> this is already the location of the collection. I am not sure what you +> are trying to do there exactly? +In this case, the PUT method is used for the creation of the resource +and not for the update. This is the reason of the 201 status code. + +In the rest_flowchart graph for the PUT/POST methods, what is the node +"new resource" ? Is it just the {true, Req, State} from the callback +defined in the content_types_accepted? + +PS: I retested and now, I have my 201 with PUT, just resource_exists has +to return false and not true ;-) + +Thanks + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 12:53:19 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 13:53:19 +0300 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need +>>> to specify the location header ok, but where? in the is_conflict +>>> function? +>> +>> Why do you need a 201? If you PUT a collection to /:collection then +>> this is already the location of the collection. I am not sure what you +>> are trying to do there exactly? +> In this case, the PUT method is used for the creation of the resource +> and not for the update. This is the reason of the 201 status code. +> +> In the rest_flowchart graph for the PUT/POST methods, what is the node +> "new resource" ? Is it just the {true, Req, State} from the callback +> defined in the content_types_accepted? +> +> PS: I retested and now, I have my 201 with PUT, just resource_exists has +> to return false and not true ;-) + +My bad I was a little confusing in my previous answer. You are right, if +the resource doesn't exist and PUT is used we get a 201 automatically. +The location header must only be provided if the resource was created +elsewhere. + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 15:26:11 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 15:26:11 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +On 27 Aug 2014, at 12:53, Lo?c Hoguin wrote: + +>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I +>>>> need +>>>> to specify the location header ok, but where? in the is_conflict +>>>> function? +>>> +>>> Why do you need a 201? If you PUT a collection to /:collection then +>>> this is already the location of the collection. I am not sure what +>>> you +>>> are trying to do there exactly? +>> In this case, the PUT method is used for the creation of the resource +>> and not for the update. This is the reason of the 201 status code. +>> +>> In the rest_flowchart graph for the PUT/POST methods, what is the +>> node +>> "new resource" ? Is it just the {true, Req, State} from the callback +>> defined in the content_types_accepted? +>> +>> PS: I retested and now, I have my 201 with PUT, just resource_exists +>> has +>> to return false and not true ;-) +> +> My bad I was a little confusing in my previous answer. You are right, +> if the resource doesn't exist and PUT is used we get a 201 +> automatically. The location header must only be provided if the +> resource was created elsewhere. + +Don't worry and thank you for your answers. + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From a.brandon.clark at gmail.com Wed Aug 27 21:06:25 2014 +From: a.brandon.clark at gmail.com (Brandon Clark) +Date: Wed, 27 Aug 2014 12:06:25 -0700 +Subject: [99s-extend] Which erlang.mk? +Message-ID: <CA+_xk0k0LEftN+Lmn-BaYpmxYaSYuaOq1Et=8cX_R5u3O_Kkng@mail.gmail.com> + +Greetings! + +I'm trying to resurrect one of my neglected ranch applications. It uses +Common Test, erlang.mk, and relx all in the usual way. When I run make +tests with all fresh dependencies, I get this: + +Doing /home/brandon/src/my_proj/deps/ranch... + +make[1]: *** No rule to make target `build-tests'. Stop. + +make: *** [build-deps-tests] Error 2 + + +A diff of my erlang.mk and deps/ranch/erlang.mk shows they are dramatically +different. Mine came from here just this morning: + +https://raw.*github.com <http://github.com>*/extend/ +erlang.mk/master/erlang.mk + +Which one is the "right" one for creating new apps? + + +Thank you! + +~BC +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140827/91c1e017/attachment.html> + +From essen at ninenines.eu Wed Aug 27 23:26:26 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 28 Aug 2014 00:26:26 +0300 +Subject: [99s-extend] Which erlang.mk? +In-Reply-To: <CA+_xk0k0LEftN+Lmn-BaYpmxYaSYuaOq1Et=8cX_R5u3O_Kkng@mail.gmail.com> +References: <CA+_xk0k0LEftN+Lmn-BaYpmxYaSYuaOq1Et=8cX_R5u3O_Kkng@mail.gmail.com> +Message-ID: <[email protected]> + +The one you downloaded from github is the correct one. It's a new +version compared to the older one. A few small things changed, +including, in this case, that build-tests was renamed to something like +ct-build-tests (please open it to make sure of the name). + +The new version allows greater customization and has a better package +index feature and other things, but breaking compatibility with older +Makefiles. The new version is labeled 1 (beginning of erlang.mk file) +while the older one has no such label. + +On 08/27/2014 10:06 PM, Brandon Clark wrote: +> Greetings! +> +> I'm trying to resurrect one of my neglected ranch applications. It uses +> Common Test, erlang.mk <http://erlang.mk>, and relx all in the usual +> way. When I run make tests with all fresh dependencies, I get this: +> +> Doing /home/brandon/src/my_proj/deps/ranch... +> +> make[1]: *** No rule to make target `build-tests'. Stop. +> +> make: *** [build-deps-tests] Error 2 +> +> +> A diff of my erlang.mk <http://erlang.mk> and deps/ranch/erlang.mk +> <http://erlang.mk> shows they are dramatically different. Mine came +> from here just this morning: +> +> https://raw._github.com +> <http://github.com>_/extend/erlang.mk/master/erlang.mk +> <http://erlang.mk/master/erlang.mk> +> +> Which one is the "right" one for creating new apps? +> +> +> Thank you! +> +> ~BC +> +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 23:41:25 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 23:41:25 +0200 +Subject: [99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ? +Message-ID: <[email protected]> + +Hi all, + +For the PUT method, the flow is + +resource_exists +if method == PUT then go to the is_conflict function. +In each function, we need to check if the resource already exists or not. + +I think we check twice, is it normal? + +Thank you, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 23:48:41 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 28 Aug 2014 00:48:41 +0300 +Subject: [99s-extend] cowboy_rest : PUT and resource_exists vs + is_conflict ? +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +For some callbacks you may need to check but only if you need to perform +a different operation when it does/doesn't. For example if you write to +files a PUT is the same operation either way, but if you write to an SQL +DB you will want to do INSERT/UPDATE depending on that. Same goes for +is_conflict and others, it depends. + +So sometimes you need to keep that info around in the state and +sometimes you don't. + +On 08/28/2014 12:41 AM, St?phane Wirtel wrote: +> Hi all, +> +> For the PUT method, the flow is +> +> resource_exists +> if method == PUT then go to the is_conflict function. +> In each function, we need to check if the resource already exists or not. +> +> I think we check twice, is it normal? +> +> Thank you, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Sat Aug 30 00:15:56 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Fri, 29 Aug 2014 23:15:56 +0100 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CA+dV7cRD-UszqUz9gv5KH4rtmW+gC6a7tEJYQco66i891+Tqbg@mail.gmail.com> + +PUT _should_ (there is no police here though) be used to either create +a resource or completely update it (it's refered to as "upsert" by +some; in Redis, for example, a similar concept would be "set"). +Partial modifications should be made using PATCH. POST is what is +commonly used to create a resource. According to +http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 412 is used +when "[t]he precondition given in one or more of the request-header +fields evaluated to false when it was tested on the server." (also: +http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24). + +- Paulo F. Oliveira + +On 27 August 2014 14:26, St?phane Wirtel <stephane at wirtel.be> wrote: +> On 27 Aug 2014, at 12:53, Lo?c Hoguin wrote: +> +>>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need +>>>>> to specify the location header ok, but where? in the is_conflict +>>>>> function? +>>>> +>>>> +>>>> Why do you need a 201? If you PUT a collection to /:collection then +>>>> this is already the location of the collection. I am not sure what you +>>>> are trying to do there exactly? +>>> +>>> In this case, the PUT method is used for the creation of the resource +>>> and not for the update. This is the reason of the 201 status code. +>>> +>>> In the rest_flowchart graph for the PUT/POST methods, what is the node +>>> "new resource" ? Is it just the {true, Req, State} from the callback +>>> defined in the content_types_accepted? +>>> +>>> PS: I retested and now, I have my 201 with PUT, just resource_exists has +>>> to return false and not true ;-) +>> +>> +>> My bad I was a little confusing in my previous answer. You are right, if +>> the resource doesn't exist and PUT is used we get a 201 automatically. The +>> location header must only be provided if the resource was created elsewhere. +> +> +> Don't worry and thank you for your answers. +> +> Stephane +> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + |