diff options
author | Loïc Hoguin <[email protected]> | 2016-08-29 12:39:49 +0200 |
---|---|---|
committer | Loïc Hoguin <[email protected]> | 2016-08-29 12:40:03 +0200 |
commit | c807880f7ac73f813b2660ea81a00f7712a4e793 (patch) | |
tree | ba1d09e9b177f230665a80513b33fbd532000ce4 /_build/static/archives/extend/2014-March.txt | |
parent | b1df25a7d9cda697513650659b781b55b40898f8 (diff) | |
download | ninenines.eu-c807880f7ac73f813b2660ea81a00f7712a4e793.tar.gz ninenines.eu-c807880f7ac73f813b2660ea81a00f7712a4e793.tar.bz2 ninenines.eu-c807880f7ac73f813b2660ea81a00f7712a4e793.zip |
Add old mailing list archives
Diffstat (limited to '_build/static/archives/extend/2014-March.txt')
-rw-r--r-- | _build/static/archives/extend/2014-March.txt | 1740 |
1 files changed, 1740 insertions, 0 deletions
diff --git a/_build/static/archives/extend/2014-March.txt b/_build/static/archives/extend/2014-March.txt new file mode 100644 index 00000000..f510662a --- /dev/null +++ b/_build/static/archives/extend/2014-March.txt @@ -0,0 +1,1740 @@ +From psihonavt at gmail.com Mon Mar 3 21:49:33 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Mon, 3 Mar 2014 22:49:33 +0200 +Subject: [99s-extend] usage of make_* command +Message-ID: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com> + +Hello, + +I have next structure of my project: +. +??? deps +? ??? cowboy +? ??? cowlib +? ??? erlang_iconv +? ??? erlydtl +? ??? mochiweb_xpath +? ??? ranch +??? ebin +? ??? fetchers.beam +? ??? parsers.beam +? ??? wasearch_sup.beam +??? erlang.mk +??? Makefile +??? _rel +? ??? .... +??? relx +??? relx.config +??? src +? ??? fetchers.erl +? ??? main_handler.erl +? ??? parsers.erl +? ??? tests +? ? ??? parsers_SUITE_data +? ? ??? parsers_SUITE.erl +? ? ??? .... +? ??? wasearch_app.erl +? ??? wasearch.app.src +? ??? wasearch_sup.erl +??? templates + ??? index.dtl + +I would prefer to store tests not in `src` directory but rather in `tests` +subdirectory. +Erlang.mk README says: You can run an individual test suite by using the +special test_* targets. For example if you have a common_test suite named +spdy and you want to run only this suite and not the others, you can use +the make test_spdy command. +And of course `make test_parsers` returns `no rule to make target` error. +Is there a way to run suites from custom directory with +`make_<mod_name_with_suite>` command? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140303/52007acc/attachment.html> + +From mark.nijhof at cre8ivethought.com Thu Mar 6 00:47:08 2014 +From: mark.nijhof at cre8ivethought.com (Mark Nijhof) +Date: Thu, 6 Mar 2014 00:47:08 +0100 +Subject: [99s-extend] Cowboy pre request filter +Message-ID: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com> + +Hi, + +I want to create a module that basically sits between the incoming request +and the http handler for that request to ensure a request is authenticated +(using a cookie), if the request is not authenticated then I like to +redirect to a specific login page (which should not be filtered). + +Is this possible with Cowboy? Should I use the onrequest hook (not sure if +I can force redirects from there) for that or is there a better way? + +Cheers, + +-Mark + +-- +Mark Nijhof +t: @MarkNijhof <https://twitter.com/MarkNijhof> +s: marknijhof +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/a517215b/attachment.html> + +From mark.nijhof at cre8ivethought.com Thu Mar 6 10:52:01 2014 +From: mark.nijhof at cre8ivethought.com (Mark Nijhof) +Date: Thu, 6 Mar 2014 10:52:01 +0100 +Subject: [99s-extend] Cowboy pre request filter +In-Reply-To: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com> +References: <CACE=TJris=4eTreF13p+bSmhfEqoKtpfj3PGyMCup1zfCRurkQ@mail.gmail.com> +Message-ID: <CACE=TJqaoxrqsCSnN44s_5x4MabgWBVfaN_pecVrShnUuU-9aQ@mail.gmail.com> + +I also found the answer to my own question: custom middleware + +I just created: + + 1 -module(authentication_middleware). + 2 + 3 -behaviour(cowboy_middleware). + 4 + 5 -export([execute/2]). + 6 + 7 execute(Req, Env) -> + 8 + 9 {Path, Req1} = cowboy_req:path(Req), + 10 + 11 case Path of + 12 <<"/login.html">> -> + 13 {ok, Req1, Env}; + 14 <<"/do_login">> -> + 15 {ok, Req1, Env}; + 16 _ -> + 17 case id3as_security:is_request_authenticated(Req1) of + 18 {error, eauth, Req2} -> + 19 {ok, Req4} = cowboy_req:reply(303, +[{<<"Location">>, <<"/login.html">>}], "", Req2), + 20 {halt, Req4}; + 21 {authenticated, _Id, Req2} -> + 22 {ok, Req2, Env} + 23 end + 24 end. + +And put this between the cowboy_router and cowboy_handler and life is all +good. + +-Mark + + + +On Thu, Mar 6, 2014 at 12:47 AM, Mark Nijhof <mark.nijhof at cre8ivethought.com +> wrote: + +> Hi, +> +> I want to create a module that basically sits between the incoming request +> and the http handler for that request to ensure a request is authenticated +> (using a cookie), if the request is not authenticated then I like to +> redirect to a specific login page (which should not be filtered). +> +> Is this possible with Cowboy? Should I use the onrequest hook (not sure if +> I can force redirects from there) for that or is there a better way? +> +> Cheers, +> +> -Mark +> +> -- +> Mark Nijhof +> t: @MarkNijhof <https://twitter.com/MarkNijhof> +> s: marknijhof +> +> + + +-- +Mark Nijhof +t: @MarkNijhof <https://twitter.com/MarkNijhof> +s: marknijhof +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/24422ef2/attachment.html> + +From essen at ninenines.eu Thu Mar 6 15:40:59 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 06 Mar 2014 15:40:59 +0100 +Subject: [99s-extend] usage of make_* command +In-Reply-To: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com> +References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com> +Message-ID: <[email protected]> + +Tests should be in ./tests, not ./src/tests. + +If you put them in ./tests everything you mentioned will work. + +On 03/03/2014 09:49 PM, Anton Koval' wrote: +> Hello, +> +> I have next structure of my project: +> . +> ??? deps +> ? ??? cowboy +> ? ??? cowlib +> ? ??? erlang_iconv +> ? ??? erlydtl +> ? ??? mochiweb_xpath +> ? ??? ranch +> ??? ebin +> ? ??? fetchers.beam +> ? ??? parsers.beam +> ? ??? wasearch_sup.beam +> ??? erlang.mk <http://erlang.mk> +> ??? Makefile +> ??? _rel +> ? ??? .... +> ??? relx +> ??? relx.config +> ??? src +> ? ??? fetchers.erl +> ? ??? main_handler.erl +> ? ??? parsers.erl +> ? ??? tests +> ? ? ??? parsers_SUITE_data +> ? ? ??? parsers_SUITE.erl +> ? ? ??? .... +> ? ??? wasearch_app.erl +> ? ??? wasearch.app.src +> ? ??? wasearch_sup.erl +> ??? templates +> ??? index.dtl +> +> I would prefer to store tests not in `src` directory but rather in +> `tests` subdirectory. +> Erlang.mk README says: You can run an individual test suite by using the +> special |test_*| targets. For example if you have a common_test suite +> named |spdy| and you want to run only this suite and not the others, you +> can use the |make test_spdy| command. +> And of course `make test_parsers` returns `no rule to make target` error. +> Is there a way to run suites from custom directory with +> `make_<mod_name_with_suite>` command? +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From psihonavt at gmail.com Thu Mar 6 15:50:01 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Thu, 6 Mar 2014 16:50:01 +0200 +Subject: [99s-extend] usage of make_* command +In-Reply-To: <[email protected]> +References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com> +Message-ID: <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com> + +Thank you for answer. +Is it common way (for OTP-based application) to store tests in `tests` +subdirectory rather then in `src/tests/`? + + +On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin <essen at ninenines.eu> wrote: + +> Tests should be in ./tests, not ./src/tests. +> +> If you put them in ./tests everything you mentioned will work. +> +> +> On 03/03/2014 09:49 PM, Anton Koval' wrote: +> +>> Hello, +>> +>> I have next structure of my project: +>> . +>> ??? deps +>> ? ??? cowboy +>> ? ??? cowlib +>> ? ??? erlang_iconv +>> ? ??? erlydtl +>> ? ??? mochiweb_xpath +>> ? ??? ranch +>> ??? ebin +>> ? ??? fetchers.beam +>> ? ??? parsers.beam +>> ? ??? wasearch_sup.beam +>> ??? erlang.mk <http://erlang.mk> +>> +>> ??? Makefile +>> ??? _rel +>> ? ??? .... +>> ??? relx +>> ??? relx.config +>> ??? src +>> ? ??? fetchers.erl +>> ? ??? main_handler.erl +>> ? ??? parsers.erl +>> ? ??? tests +>> ? ? ??? parsers_SUITE_data +>> ? ? ??? parsers_SUITE.erl +>> ? ? ??? .... +>> ? ??? wasearch_app.erl +>> ? ??? wasearch.app.src +>> ? ??? wasearch_sup.erl +>> ??? templates +>> ??? index.dtl +>> +>> I would prefer to store tests not in `src` directory but rather in +>> `tests` subdirectory. +>> Erlang.mk README says: You can run an individual test suite by using the +>> special |test_*| targets. For example if you have a common_test suite +>> named |spdy| and you want to run only this suite and not the others, you +>> can use the |make test_spdy| command. +>> And of course `make test_parsers` returns `no rule to make target` error. +>> Is there a way to run suites from custom directory with +>> `make_<mod_name_with_suite>` command? +>> +>> +>> _______________________________________________ +>> 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/20140306/6fa8fe3b/attachment.html> + +From essen at ninenines.eu Thu Mar 6 15:51:58 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 06 Mar 2014 15:51:58 +0100 +Subject: [99s-extend] usage of make_* command +In-Reply-To: <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com> +References: <CAD9h6NFVnE3y6QDj9WPMA8sKZWwzE6==9c8MzJitE=GYEocgmw@mail.gmail.com> <[email protected]> + <CAD9h6NHaXQFX518wFdLNpycFVuu0bXN4NKzMqztnVN0rLu6BeA@mail.gmail.com> +Message-ID: <[email protected]> + +Sorry I meant ./test/ not ./tests/ + +But yes. That's how OTP does it. + +On 03/06/2014 03:50 PM, Anton Koval' wrote: +> Thank you for answer. +> Is it common way (for OTP-based application) to store tests in `tests` +> subdirectory rather then in `src/tests/`? +> +> +> On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin <essen at ninenines.eu +> <mailto:essen at ninenines.eu>> wrote: +> +> Tests should be in ./tests, not ./src/tests. +> +> If you put them in ./tests everything you mentioned will work. +> +> +> On 03/03/2014 09:49 PM, Anton Koval' wrote: +> +> Hello, +> +> I have next structure of my project: +> . +> ??? deps +> ? ??? cowboy +> ? ??? cowlib +> ? ??? erlang_iconv +> ? ??? erlydtl +> ? ??? mochiweb_xpath +> ? ??? ranch +> ??? ebin +> ? ??? fetchers.beam +> ? ??? parsers.beam +> ? ??? wasearch_sup.beam +> ??? erlang.mk <http://erlang.mk> <http://erlang.mk> +> +> ??? Makefile +> ??? _rel +> ? ??? .... +> ??? relx +> ??? relx.config +> ??? src +> ? ??? fetchers.erl +> ? ??? main_handler.erl +> ? ??? parsers.erl +> ? ??? tests +> ? ? ??? parsers_SUITE_data +> ? ? ??? parsers_SUITE.erl +> ? ? ??? .... +> ? ??? wasearch_app.erl +> ? ??? wasearch.app.src +> ? ??? wasearch_sup.erl +> ??? templates +> ??? index.dtl +> +> I would prefer to store tests not in `src` directory but rather in +> `tests` subdirectory. +> Erlang.mk README says: You can run an individual test suite by +> using the +> special |test_*| targets. For example if you have a common_test +> suite +> named |spdy| and you want to run only this suite and not the +> others, you +> can use the |make test_spdy| command. +> And of course `make test_parsers` returns `no rule to make +> target` error. +> Is there a way to run suites from custom directory with +> `make_<mod_name_with_suite>` command? +> +> +> _________________________________________________ +> 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 lloyd at writersglen.com Thu Mar 6 21:29:59 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Thu, 6 Mar 2014 15:29:59 -0500 (EST) +Subject: [99s-extend] Trying to grok erlang.mk +Message-ID: <[email protected]> + +Hello, + +To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this: + +min + erlang.mk + Makefile + src + min.app.src + min.erl + +*** Where Makefile is: + +PROJECT = min + +include erlang.mk + +*** min.app.src is: + +{application, min, + [{description,[]}, + {vsn,"0.1.0"}, + {registered,[]}, + {applications,[kernel,stdlib]}, + {env,[]}, + {modules,[]}]}. + +*** and min.erl is: + +-module(min). + +-export([hello/0]). + +hello() -> + io:format("Hello min!~n~n"). + +*** But when I call make, I get this: + +/min$ make + ERLC min.erl + APP min .app.src +cat: src/min: No such file or directory +cat: .app.src: No such file or directory +sed: can't read .app: No such file or directory +make: *** [app] Error 2 + +*** Observations + +min.erl compiles just fine +min.app.src breaks the compile + +*** Questions: + +1) How can I correct this? +2) How can I structure directories and make files for a project that involves several applications? + +Many thanks, + +LRP + + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From ivan at llaisdy.com Fri Mar 7 13:37:27 2014 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Fri, 07 Mar 2014 12:37:27 +0000 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Dear Lloyd + +I've just tried this with file layout and contents copied from your +email, and make works fine here I'm afraid. + +One odd thing I noticed in your make output ... + + > /min$ make + > ERLC min.erl + > APP min .app.src + > cat: src/min: No such file or directory + > cat: .app.src: No such file or directory + > sed: can't read .app: No such file or directory + > make: *** [app] Error 2 + +... is that in the APP line, the filename min.app.src has a space in it, +and it looks (in the cat lines) like it's broken down into src/min and +.app.src (ie ./.app.src). I can't imagine why that's happening, but +that's what's causing the problem I should think. + + > 2) How can I structure directories and make files for a project + > that involves several applications? + +I don't know if it's the "correct" way with erlang.mk but, as a refugee +from rebar, I have apps set out rebar-style and use old-school recursive +make. e.g.: + +max/ + erlang.mk + Makefile + apps/ + app1/ + Makefile + src/ + app2/ + Makefile + src/ + +Top level Makefile doesn't need to include erlang.mk, and has lines like: + +all: + $(MAKE) -C apps/app1 + $(MAKE) -C apps/app2 + +Lower level Makefiles include erlang.mk. + +Best wishes + +Ivan + + +On 06/03/2014 20:29, lloyd at writersglen.com wrote: +> Hello, +> +> To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this: +> +> min +> erlang.mk +> Makefile +> src +> min.app.src +> min.erl +> +> *** Where Makefile is: +> +> PROJECT = min +> +> include erlang.mk +> +> *** min.app.src is: +> +> {application, min, +> [{description,[]}, +> {vsn,"0.1.0"}, +> {registered,[]}, +> {applications,[kernel,stdlib]}, +> {env,[]}, +> {modules,[]}]}. +> +> *** and min.erl is: +> +> -module(min). +> +> -export([hello/0]). +> +> hello() -> +> io:format("Hello min!~n~n"). +> +> *** But when I call make, I get this: +> +> /min$ make +> ERLC min.erl +> APP min .app.src +> cat: src/min: No such file or directory +> cat: .app.src: No such file or directory +> sed: can't read .app: No such file or directory +> make: *** [app] Error 2 +> +> *** Observations +> +> min.erl compiles just fine +> min.app.src breaks the compile +> +> *** Questions: +> +> 1) How can I correct this? +> 2) How can I structure directories and make files for a project that involves several applications? +> +> Many thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From essen at ninenines.eu Fri Mar 7 17:56:01 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 07 Mar 2014 17:56:01 +0100 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote: +> PROJECT = min + +You probably have an extra space at the end here, and erlang.mk doesn't +trim them I guess. Please open a ticket! + +-- +Lo?c Hoguin +http://ninenines.eu + + +From ivan at llaisdy.com Fri Mar 7 17:58:40 2014 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Fri, 07 Mar 2014 16:58:40 +0000 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Yes, that's it! I've just tried it. + +Good old make :) + +On 07/03/2014 16:56, Lo?c Hoguin wrote: +> On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote: +>> PROJECT = min +> +> You probably have an extra space at the end here, and erlang.mk doesn't +> trim them I guess. Please open a ticket! +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From lloyd at writersglen.com Mon Mar 10 20:44:27 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Mon, 10 Mar 2014 15:44:27 -0400 (EDT) +Subject: [99s-extend] =?utf-8?q?Getting_started_error=3A___behaviour_cowbo?= + =?utf-8?q?y=5Fhttp=5Fhandler_undefined?= +Message-ID: <[email protected]> + +Hello, + +I've slavishly emulated the "Getting started" example in the guide: + +http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ + +But, when I compile I get this error: + +yada yada + ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +compile: warnings being treated as errors +src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +make: *** [ebin/hello_erlang.app] Error 1 + +Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam + +However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. + +% -behavior(cowboy_http_handler). + +Could this be a bug in Getting started or some dunder-headed thing on my end? + +Thanks, + +LRP + + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From essen at ninenines.eu Mon Mar 10 21:36:22 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 10 Mar 2014 21:36:22 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Try updating Erlang or Cowboy, this isn't the first time this happens +and I fixed something at some point. + +Also see if you have ERL_LIBS already defined, in which case there might +be a bug in Cowboy. + +On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +> Hello, +> +> I've slavishly emulated the "Getting started" example in the guide: +> +> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +> +> But, when I compile I get this error: +> +> yada yada +> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +> compile: warnings being treated as errors +> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +> make: *** [ebin/hello_erlang.app] Error 1 +> +> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +> +> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +> +> % -behavior(cowboy_http_handler). +> +> Could this be a bug in Getting started or some dunder-headed thing on my end? +> +> Thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Wed Mar 12 23:51:04 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Wed, 12 Mar 2014 18:51:04 -0400 (EDT) +Subject: [99s-extend] + =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?= + =?utf-8?q?=5Fhttp=5Fhandler_undefined?= +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Hi Lo?c, + +Thanks for help. + +I'm running cowboy master from GitHub and Erlang R16B02. + +$ echo $ERL_LIBS + +...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. + +E.g.: /home/lloyd/Programming/Erlang/zippity/apps + +I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>. + +Thanks again, + +LRP + +-----Original Message----- +From: "Lo?c Hoguin" <essen at ninenines.eu> +Sent: Monday, March 10, 2014 4:36pm +To: lloyd at writersglen.com, extend at lists.ninenines.eu +Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + +Try updating Erlang or Cowboy, this isn't the first time this happens +and I fixed something at some point. + +Also see if you have ERL_LIBS already defined, in which case there might +be a bug in Cowboy. + +On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +> Hello, +> +> I've slavishly emulated the "Getting started" example in the guide: +> +> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +> +> But, when I compile I get this error: +> +> yada yada +> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +> compile: warnings being treated as errors +> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +> make: *** [ebin/hello_erlang.app] Error 1 +> +> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +> +> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +> +> % -behavior(cowboy_http_handler). +> +> Could this be a bug in Getting started or some dunder-headed thing on my end? +> +> Thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> 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 Wed Mar 12 23:57:16 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 12 Mar 2014 23:57:16 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Can you try again after running "unset ERL_LIBS"? + +On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +> Hi Lo?c, +> +> Thanks for help. +> +> I'm running cowboy master from GitHub and Erlang R16B02. +> +> $ echo $ERL_LIBS +> +> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +> +> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +> +> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>. +> +> Thanks again, +> +> LRP +> +> -----Original Message----- +> From: "Lo?c Hoguin" <essen at ninenines.eu> +> Sent: Monday, March 10, 2014 4:36pm +> To: lloyd at writersglen.com, extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Try updating Erlang or Cowboy, this isn't the first time this happens +> and I fixed something at some point. +> +> Also see if you have ERL_LIBS already defined, in which case there might +> be a bug in Cowboy. +> +> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>> Hello, +>> +>> I've slavishly emulated the "Getting started" example in the guide: +>> +>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>> +>> But, when I compile I get this error: +>> +>> yada yada +>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>> compile: warnings being treated as errors +>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>> make: *** [ebin/hello_erlang.app] Error 1 +>> +>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>> +>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>> +>> % -behavior(cowboy_http_handler). +>> +>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>> +>> Thanks, +>> +>> LRP +>> +>> +>> ********************************************* +>> My books: +>> +>> THE GOSPEL OF ASHES +>> http://thegospelofashes.com +>> +>> Strength is not enough. Do they have the courage +>> and the cunning? Can they survive long enough to +>> save the lives of millions? +>> +>> FREEIN' PANCHO +>> http://freeinpancho.com +>> +>> A community of misfits help a troubled boy find his way +>> +>> AYA TAKEO +>> http://ayatakeo.com +>> +>> Star-crossed love, war and power in an alternative +>> universe +>> +>> Available through Amazon or by request from your +>> favorite bookstore +>> +>> +>> ********************************************** +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Thu Mar 13 00:43:16 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Wed, 12 Mar 2014 19:43:16 -0400 (EDT) +Subject: [99s-extend] + =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?= + =?utf-8?q?=5Fhttp=5Fhandler_undefined?= +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Hi, + +That fixed it! + +But where can I go to understand why and prevent it in future? + +I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system? + +Many thanks! + +Lloyd + +-----Original Message----- +From: "Lo?c Hoguin" <essen at ninenines.eu> +Sent: Wednesday, March 12, 2014 6:57pm +To: lloyd at writersglen.com +Cc: extend at lists.ninenines.eu +Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + +Can you try again after running "unset ERL_LIBS"? + +On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +> Hi Lo?c, +> +> Thanks for help. +> +> I'm running cowboy master from GitHub and Erlang R16B02. +> +> $ echo $ERL_LIBS +> +> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +> +> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +> +> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>. +> +> Thanks again, +> +> LRP +> +> -----Original Message----- +> From: "Lo?c Hoguin" <essen at ninenines.eu> +> Sent: Monday, March 10, 2014 4:36pm +> To: lloyd at writersglen.com, extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Try updating Erlang or Cowboy, this isn't the first time this happens +> and I fixed something at some point. +> +> Also see if you have ERL_LIBS already defined, in which case there might +> be a bug in Cowboy. +> +> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>> Hello, +>> +>> I've slavishly emulated the "Getting started" example in the guide: +>> +>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>> +>> But, when I compile I get this error: +>> +>> yada yada +>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>> compile: warnings being treated as errors +>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>> make: *** [ebin/hello_erlang.app] Error 1 +>> +>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>> +>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>> +>> % -behavior(cowboy_http_handler). +>> +>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>> +>> Thanks, +>> +>> LRP +>> +>> +>> ********************************************* +>> My books: +>> +>> THE GOSPEL OF ASHES +>> http://thegospelofashes.com +>> +>> Strength is not enough. Do they have the courage +>> and the cunning? Can they survive long enough to +>> save the lives of millions? +>> +>> FREEIN' PANCHO +>> http://freeinpancho.com +>> +>> A community of misfits help a troubled boy find his way +>> +>> AYA TAKEO +>> http://ayatakeo.com +>> +>> Star-crossed love, war and power in an alternative +>> universe +>> +>> Available through Amazon or by request from your +>> favorite bookstore +>> +>> +>> ********************************************** +>> +>> _______________________________________________ +>> 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 Thu Mar 13 00:46:57 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 13 Mar 2014 00:46:57 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +It's explained here: http://www.erlang.org/doc/man/code.html + +I am not sure why it caused issues on your system, possibly Erlang +ignored it because there was an invalid folder in there. I don't really +know. + +On 03/13/2014 12:43 AM, lloyd at writersglen.com wrote: +> Hi, +> +> That fixed it! +> +> But where can I go to understand why and prevent it in future? +> +> I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system? +> +> Many thanks! +> +> Lloyd +> +> -----Original Message----- +> From: "Lo?c Hoguin" <essen at ninenines.eu> +> Sent: Wednesday, March 12, 2014 6:57pm +> To: lloyd at writersglen.com +> Cc: extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Can you try again after running "unset ERL_LIBS"? +> +> On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +>> Hi Lo?c, +>> +>> Thanks for help. +>> +>> I'm running cowboy master from GitHub and Erlang R16B02. +>> +>> $ echo $ERL_LIBS +>> +>> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +>> +>> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +>> +>> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>. +>> +>> Thanks again, +>> +>> LRP +>> +>> -----Original Message----- +>> From: "Lo?c Hoguin" <essen at ninenines.eu> +>> Sent: Monday, March 10, 2014 4:36pm +>> To: lloyd at writersglen.com, extend at lists.ninenines.eu +>> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +>> +>> Try updating Erlang or Cowboy, this isn't the first time this happens +>> and I fixed something at some point. +>> +>> Also see if you have ERL_LIBS already defined, in which case there might +>> be a bug in Cowboy. +>> +>> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>>> Hello, +>>> +>>> I've slavishly emulated the "Getting started" example in the guide: +>>> +>>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>>> +>>> But, when I compile I get this error: +>>> +>>> yada yada +>>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>>> compile: warnings being treated as errors +>>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>>> make: *** [ebin/hello_erlang.app] Error 1 +>>> +>>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>>> +>>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>>> +>>> % -behavior(cowboy_http_handler). +>>> +>>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>>> +>>> Thanks, +>>> +>>> LRP +>>> +>>> +>>> ********************************************* +>>> My books: +>>> +>>> THE GOSPEL OF ASHES +>>> http://thegospelofashes.com +>>> +>>> Strength is not enough. Do they have the courage +>>> and the cunning? Can they survive long enough to +>>> save the lives of millions? +>>> +>>> FREEIN' PANCHO +>>> http://freeinpancho.com +>>> +>>> A community of misfits help a troubled boy find his way +>>> +>>> AYA TAKEO +>>> http://ayatakeo.com +>>> +>>> Star-crossed love, war and power in an alternative +>>> universe +>>> +>>> Available through Amazon or by request from your +>>> favorite bookstore +>>> +>>> +>>> ********************************************** +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From joshua.mcquistan at mcq.io Thu Mar 13 02:41:12 2014 +From: joshua.mcquistan at mcq.io (Joshua McQuistan) +Date: Thu, 13 Mar 2014 01:41:12 +0000 +Subject: [99s-extend] Updating Cowboy applications +Message-ID: <[email protected]> + +Hello all, + +I have written a Cowboy application that works fine over localhost. I'm +now looking at ways of deploying and updating it i.e., moving from dev +to prod in a nice manner. + +I have dug around the archives and have found that Cowboy does not +support hot code reloading meaning either a restart of the vm or playing +with code:reload_file is necessary. + +The latter suggests a possible rewriting of OTP's code loading mechanism +and seems like it might be sensible to avoid. + +The other approach then is a restart. In previous (non-Cowboy) set ups +I've used nginx on port 80 / 443 that talks to the web app via a unix +socket (e.g., "web/socket"). When updating I'll start a new instance on +a new socket (e.g., "web/socket.new") then rely on the file system's +"mv" to switch it to "web/socket"; this works because the underlying +file system guarantees mv to be atomic (or at least to never see a +missing file). I can then ask the old process to shut down nicely in the +background. + +For this to work it would require Cowby / Ranch to be able to listen on +unix sockets. A glance at the documentation suggests that unix sockets +aren't available, is this the case? What's the feasibility of it getting +added? + +It might just be simpler to load-balance across multiple servers and +safely take them out one at a time while updating. + +My other question is, how do others approach this problem? Did I miss +something vitally obvious? + +Regards, +Joshua + + +From essen at ninenines.eu Thu Mar 13 14:22:03 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 13 Mar 2014 14:22:03 +0100 +Subject: [99s-extend] Updating Cowboy applications +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Deploying is easy: releases. + +The "getting started" chapter of the guide, and all the examples use +that and it should be pretty easy to do. + +You can reload Cowboy modules directly using l(module). You can reload +most Ranch modules too but some of them will require using sys. Ranch +will get support for upgrades as soon as I finish the upgrade test +suite, but it's still low priority. + +And upgrade of Cowboy processes can only be added after we make them +special processes, which is still a way to go. + +There is no plans for supporting unix sockets for the simple reason that +it is not portable. On the other hand, if you use a separate library to +open a socket and give it to Ranch (socket option), possibly writing a +specific transport module for it, then it's very possible that you can +use unix sockets (and if it works, please do send feedback). + +On 03/13/2014 02:41 AM, Joshua McQuistan wrote: +> Hello all, +> +> I have written a Cowboy application that works fine over localhost. I'm +> now looking at ways of deploying and updating it i.e., moving from dev +> to prod in a nice manner. +> +> I have dug around the archives and have found that Cowboy does not +> support hot code reloading meaning either a restart of the vm or playing +> with code:reload_file is necessary. +> +> The latter suggests a possible rewriting of OTP's code loading mechanism +> and seems like it might be sensible to avoid. +> +> The other approach then is a restart. In previous (non-Cowboy) set ups +> I've used nginx on port 80 / 443 that talks to the web app via a unix +> socket (e.g., "web/socket"). When updating I'll start a new instance on +> a new socket (e.g., "web/socket.new") then rely on the file system's +> "mv" to switch it to "web/socket"; this works because the underlying +> file system guarantees mv to be atomic (or at least to never see a +> missing file). I can then ask the old process to shut down nicely in the +> background. +> +> For this to work it would require Cowby / Ranch to be able to listen on +> unix sockets. A glance at the documentation suggests that unix sockets +> aren't available, is this the case? What's the feasibility of it getting +> added? +> +> It might just be simpler to load-balance across multiple servers and +> safely take them out one at a time while updating. +> +> My other question is, how do others approach this problem? Did I miss +> something vitally obvious? +> +> Regards, +> Joshua +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From joshua.mcquistan at mcq.io Thu Mar 13 15:23:09 2014 +From: joshua.mcquistan at mcq.io (Joshua McQuistan) +Date: Thu, 13 Mar 2014 14:23:09 +0000 +Subject: [99s-extend] Updating Cowboy applications +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +> +> I wish I knew enough to answer your question. But I do hope you publish a tutorial documenting your solution for those following you down the trail. + +Will do. + +On 13/03/14 13:22, Lo?c Hoguin wrote: +> +> There is no plans for supporting unix sockets for the simple reason that +> it is not portable. On the other hand, if you use a separate library to +> open a socket and give it to Ranch (socket option), possibly writing a +> specific transport module for it, then it's very possible that you can +> use unix sockets (and if it works, please do send feedback). + +I had missed this last night, I will try passing the socket down and see +if it works. + +I can also see the gen_tcp:listen in ranch_tcp but I'd prefer to avoid that. + + +From Christopher.Phillips at turner.com Fri Mar 14 19:52:07 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 18:52:07 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the body +Message-ID: <CF48C816.16B3B%[email protected]> + +On a dev server I had a Cowboy app suddenly start returning timeouts when calling cowboy_req:body_qs(Request), with surprising frequency, which in turn led to 500s back to the calling client. It only appeared to happen when hitting one particular resource, and was sporadic, and I was wondering if there might be some explanation related to Cowboy (as opposed to maybe really weird VM issues). For full disclosure, we would first check the body with cowboy_req:body(Request) as part of an access log, then ignore the returned cowboy_req:req() that call passed back, since we could not then stream the body off of it again. It was working fine, so I don't think it was related, but it seems more solid now after I removed it and I don't know if that's related or not. + + + +Here is an example request that dumped when the process died - + + +{req,[{socket,#Port<0.7113>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1805.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{10,188,32,225},53188}},{host,<<"bps-feedschedulervip1.turner.com">>},{host_info,undefined},{port,8091},{path,<<"/encoders/Player1/record">>},{path_info,[<<"record">>]},{qs,<<"authToken=...">>},{qs_vals,[{<<"authToken">>,<<"...">>}]},{bindings,[{id,<<"Player1">>}]},{headers,[{<<"host">>,<<"bps-feedschedulervip1.turner.com:8091">>},{<<"content-type">>,<<"application/x-www-form-urlencoded; charset=UTF-8">>},{<<"origin">>,<<"http://bps-newstrondev1.turner.com">>},{<<"content-length">>,<<"48">>},{<<"connection">>,<<"keep-alive">>},{<<"accept">>,<<"application/json, text/javascript, */*; q=0.01">>},{<<"user-agent">>,<<"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9">>},{<<"referer">>,<<"http://bps-newstrondev1.turner.com/newstron/record/record.html">>},{<<"accept-language">>,<<"en-us">>},{<<"accept-encoding">>,<<"gzip, deflate">>}]},{p_headers,[{<<"content-type">>,{<<"application">>,<<"x-www-form-urlencoded">>,[{<<"charset">>,<<"utf-8">>}]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"application">>,<<"json">>,[]},1000,[]},{{<<"text">>,<<"javascript">>,[]},1000,[]},{{<<"*">>,<<"*">>,[]},10,[]}]},{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[{charset,undefined},{media_type,{<<"application">>,<<"json">>,[]}}]},{body_state,waiting},{multipart,undefined},{buffer,<<>>},{resp_compress,false},{resp_state,waiting},{resp_headers,[{<<"content-type">>,[<<"application">>,<<"/">>,<<"json">>,<<>>]},{<<"Access-Control-Allow-Origin">>,<<"*">>}]},{resp_body,<<>>},{onresponse,#Fun<access_log_responder.onresponse.4>}]} + + + + +As I said, it may be just due to VM issues or something, but I figured I'd ask in case there was any obvious issue. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20140314/b2f802d3/attachment.html> + +From essen at ninenines.eu Fri Mar 14 19:56:38 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 14 Mar 2014 19:56:38 +0100 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <CF48C816.16B3B%[email protected]> +References: <CF48C816.16B3B%[email protected]> +Message-ID: <[email protected]> + +Cowboy does have a timeout too small, that will be fixed soon (by making +it configurable, per body-reading call). It will be in the next release. + +On the other hand there's something weird in what you said. + +On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +> first check the body with cowboy_req:body(Request) as part of an access +> log, then ignore the returned cowboy_req:req() that call passed back, +> since we could not then stream the body off of it again. It was working +> fine, so I don't think it was related, but it seems more solid now after +> I removed it and I don't know if that's related or not. + +If you ignore the Req being returned, especially after a body-reading +call, then Cowboy will not be able to figure out that you actually read +it, and will attempt to read it again to skip it, leading to issues. + +-- +Lo?c Hoguin +http://ninenines.eu + + +From Christopher.Phillips at turner.com Fri Mar 14 20:07:40 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 19:07:40 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <[email protected]> +References: <CF48C816.16B3B%[email protected]> +Message-ID: <CF48CAF9.16B5A%[email protected]> + + This body is -small-. 48 bytes was my test data (per the +content-length). That shouldn't take 5 seconds to read, and usually it +took a millisecond or two, and returned to the client (despite actually +controlling some hardware across a network and such) within a second. And +it was ND; I tested this thing a couple of times locally and it appeared +to work, and even deployed onto a VM it worked some of the time (as I +said, might have been hardware or some other weirdness). + + So can we only read the body once? Or what's the right approach if I +want to access the body in both a module registered to the +onrequest/onresponse callbacks, and in the REST handler? + +On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote: + +>Cowboy does have a timeout too small, that will be fixed soon (by making +>it configurable, per body-reading call). It will be in the next release. +> +>On the other hand there's something weird in what you said. +> +>On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>> first check the body with cowboy_req:body(Request) as part of an access +>> log, then ignore the returned cowboy_req:req() that call passed back, +>> since we could not then stream the body off of it again. It was working +>> fine, so I don't think it was related, but it seems more solid now after +>> I removed it and I don't know if that's related or not. +> +>If you ignore the Req being returned, especially after a body-reading +>call, then Cowboy will not be able to figure out that you actually read +>it, and will attempt to read it again to skip it, leading to issues. +> +>-- +>Lo?c Hoguin +>http://ninenines.eu + + + +From essen at ninenines.eu Fri Mar 14 20:11:27 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 14 Mar 2014 20:11:27 +0100 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <CF48CAF9.16B5A%[email protected]> +References: <CF48C816.16B3B%[email protected]> + <CF48CAF9.16B5A%[email protected]> +Message-ID: <[email protected]> + +Yep, only once. All functions that return {ok, ...} are like this. +There's no right approach, that's left as an exercise to the developer. :-) + +You can probably use cowboy_req:set_meta/meta if you really need to pass +it around. + +On 03/14/2014 08:07 PM, Phillips, Christopher wrote: +> This body is -small-. 48 bytes was my test data (per the +> content-length). That shouldn't take 5 seconds to read, and usually it +> took a millisecond or two, and returned to the client (despite actually +> controlling some hardware across a network and such) within a second. And +> it was ND; I tested this thing a couple of times locally and it appeared +> to work, and even deployed onto a VM it worked some of the time (as I +> said, might have been hardware or some other weirdness). +> +> So can we only read the body once? Or what's the right approach if I +> want to access the body in both a module registered to the +> onrequest/onresponse callbacks, and in the REST handler? +> +> On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote: +> +>> Cowboy does have a timeout too small, that will be fixed soon (by making +>> it configurable, per body-reading call). It will be in the next release. +>> +>> On the other hand there's something weird in what you said. +>> +>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>>> first check the body with cowboy_req:body(Request) as part of an access +>>> log, then ignore the returned cowboy_req:req() that call passed back, +>>> since we could not then stream the body off of it again. It was working +>>> fine, so I don't think it was related, but it seems more solid now after +>>> I removed it and I don't know if that's related or not. +>> +>> If you ignore the Req being returned, especially after a body-reading +>> call, then Cowboy will not be able to figure out that you actually read +>> it, and will attempt to read it again to skip it, leading to issues. +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From Christopher.Phillips at turner.com Fri Mar 14 20:13:31 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 19:13:31 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <[email protected]> +References: <CF48C816.16B3B%[email protected]> + <CF48CAF9.16B5A%[email protected]> +Message-ID: <CF48CD10.16B7C%[email protected]> + + Hmm, okay. Thanks Loic. + +On 3/14/14, 3:11 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote: + +>Yep, only once. All functions that return {ok, ...} are like this. +>There's no right approach, that's left as an exercise to the developer. +>:-) +> +>You can probably use cowboy_req:set_meta/meta if you really need to pass +>it around. +> +>On 03/14/2014 08:07 PM, Phillips, Christopher wrote: +>> This body is -small-. 48 bytes was my test data (per the +>> content-length). That shouldn't take 5 seconds to read, and usually it +>> took a millisecond or two, and returned to the client (despite actually +>> controlling some hardware across a network and such) within a second. +>>And +>> it was ND; I tested this thing a couple of times locally and it appeared +>> to work, and even deployed onto a VM it worked some of the time (as I +>> said, might have been hardware or some other weirdness). +>> +>> So can we only read the body once? Or what's the right approach if I +>> want to access the body in both a module registered to the +>> onrequest/onresponse callbacks, and in the REST handler? +>> +>> On 3/14/14, 2:56 PM, "Lo?c Hoguin" <essen at ninenines.eu> wrote: +>> +>>> Cowboy does have a timeout too small, that will be fixed soon (by +>>>making +>>> it configurable, per body-reading call). It will be in the next +>>>release. +>>> +>>> On the other hand there's something weird in what you said. +>>> +>>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>>>> first check the body with cowboy_req:body(Request) as part of an +>>>>access +>>>> log, then ignore the returned cowboy_req:req() that call passed back, +>>>> since we could not then stream the body off of it again. It was +>>>>working +>>>> fine, so I don't think it was related, but it seems more solid now +>>>>after +>>>> I removed it and I don't know if that's related or not. +>>> +>>> If you ignore the Req being returned, especially after a body-reading +>>> call, then Cowboy will not be able to figure out that you actually read +>>> it, and will attempt to read it again to skip it, leading to issues. +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +>-- +>Lo?c Hoguin +>http://ninenines.eu + + + |