diff options
Diffstat (limited to 'archives/extend/2015-January.txt')
-rw-r--r-- | archives/extend/2015-January.txt | 1189 |
1 files changed, 1189 insertions, 0 deletions
diff --git a/archives/extend/2015-January.txt b/archives/extend/2015-January.txt new file mode 100644 index 00000000..d94c2440 --- /dev/null +++ b/archives/extend/2015-January.txt @@ -0,0 +1,1189 @@ +From e at bestmx.net Sat Jan 10 14:55:58 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 14:55:58 +0100 +Subject: [99s-extend] websocket over ssl +Message-ID: <[email protected]> + +Hello all. + +I am trying to alter my cowboy-based websocket server from plain to SSL +connection. +And I found out that I have failed to understand very basics of the +combination of WS and SSL. + +As far as i've understood the very nature of the WS it is a bit altered +http connection (i open the http connection first, and then i change its +status to WS) + +On the other hand the whole "HTTP story" could be wrapped into SSL, so +that SSL is an outer layer of data encoding (as seen transparent by an +application) + +thus, +if I open HTTPS connection (which implies SSL enveloping) and then alter +the connection status to WS, the whole "WS story" appears naturally +INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. + +Is it true? + +In this regard i can hardly find a place in this world for the "WSS" +term, what does it stand for? + +Please, help me fit it in my head. + +However, i might be confusing some Client-Side entities, that are +involved in the process of starting up my WebSocket. + +I am using a Browser with JavaScript. + +The semantics of the very WebSocket.start() operation is not enough +clear to me. Please, do not laugh. + +when i do JS WebSocket.start() does it: +(a) opens an http connection and then alters it to WS +(b) alters the connection in the context of which the JS process is running +???? + +I'll be damned if the answer was lying on the surface of the internet! + +The third part of this ugly question is about cowboy actually. +How all these entities mentioned above do map into my_app.erl file? +what particular bits of cowboy's "configuration" (may i call this +particular piece of code a "setup" or "config"?) affect what aspects of +the connection initialization. + +well, i am afraid it could be put in a simpler way: +"Exactly When and Where the WSS story begins?" + + +From essen at ninenines.eu Sat Jan 10 15:21:04 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sat, 10 Jan 2015 15:21:04 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +Assuming you have no problem understanding HTTPS, the only differences +between plain Websocket and HTTPS Websocket are as follow: + +In your browser, your ws:// links become wss:// links. + +In Cowboy, use start_https instead of start_http. There is no change +required in your code otherwise. + +It may or may not be possible to use wss:// from an HTTP page or ws:// +from an HTTPS page, I'm not too up to date on that one. Otherwise, ws:// +from HTTP page or wss:// from HTTPS page works as intended. + +There is no requirement that a Websocket connection is initiated on a +new TCP connection. I am not sure if browsers reuse connections or not. + +On 01/10/2015 02:55 PM, e at bestmx.net wrote: +> Hello all. +> +> I am trying to alter my cowboy-based websocket server from plain to SSL +> connection. +> And I found out that I have failed to understand very basics of the +> combination of WS and SSL. +> +> As far as i've understood the very nature of the WS it is a bit altered +> http connection (i open the http connection first, and then i change its +> status to WS) +> +> On the other hand the whole "HTTP story" could be wrapped into SSL, so +> that SSL is an outer layer of data encoding (as seen transparent by an +> application) +> +> thus, +> if I open HTTPS connection (which implies SSL enveloping) and then alter +> the connection status to WS, the whole "WS story" appears naturally +> INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. +> +> Is it true? +> +> In this regard i can hardly find a place in this world for the "WSS" +> term, what does it stand for? +> +> Please, help me fit it in my head. +> +> However, i might be confusing some Client-Side entities, that are +> involved in the process of starting up my WebSocket. +> +> I am using a Browser with JavaScript. +> +> The semantics of the very WebSocket.start() operation is not enough +> clear to me. Please, do not laugh. +> +> when i do JS WebSocket.start() does it: +> (a) opens an http connection and then alters it to WS +> (b) alters the connection in the context of which the JS process is running +> ???? +> +> I'll be damned if the answer was lying on the surface of the internet! +> +> The third part of this ugly question is about cowboy actually. +> How all these entities mentioned above do map into my_app.erl file? +> what particular bits of cowboy's "configuration" (may i call this +> particular piece of code a "setup" or "config"?) affect what aspects of +> the connection initialization. +> +> well, i am afraid it could be put in a simpler way: +> "Exactly When and Where the WSS story begins?" +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Sat Jan 10 15:28:52 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 15:28:52 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +> In Cowboy, use start_https instead of start_http. + +thanx! it makes a lot of sense for me. +tell me please what deps should be declared in the .app file? + +is the following correct? + + {applications, [ + kernel, + stdlib, + crypto, + public_key, + ssl, + cowboy + ]}, + +does the order matters? + +(i borrowed that from the internet without deep understanding of the +roles of each app on the list) + +From essen at ninenines.eu Sat Jan 10 15:34:41 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sat, 10 Jan 2015 15:34:41 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter +I think. + +On 01/10/2015 03:28 PM, e at bestmx.net wrote: +>> In Cowboy, use start_https instead of start_http. +> +> thanx! it makes a lot of sense for me. +> tell me please what deps should be declared in the .app file? +> +> is the following correct? +> +> {applications, [ +> kernel, +> stdlib, +> crypto, +> public_key, +> ssl, +> cowboy +> ]}, +> +> does the order matters? +> +> (i borrowed that from the internet without deep understanding of the +> roles of each app on the list) + +-- +Lo?c Hoguin +http://ninenines.eu + +From lee.sylvester at gmail.com Sat Jan 10 15:39:41 2015 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Sat, 10 Jan 2015 14:39:41 +0000 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +I use Cowboy for websockets, but I find it?s a lot easier (and less stressful) to run Nginx in front of it to provide the SSL layer. + +Lee + + +> On 10 Jan 2015, at 13:55, e at bestmx.net wrote: +> +> Hello all. +> +> I am trying to alter my cowboy-based websocket server from plain to SSL connection. +> And I found out that I have failed to understand very basics of the combination of WS and SSL. +> +> As far as i've understood the very nature of the WS it is a bit altered http connection (i open the http connection first, and then i change its status to WS) +> +> On the other hand the whole "HTTP story" could be wrapped into SSL, so that SSL is an outer layer of data encoding (as seen transparent by an application) +> +> thus, +> if I open HTTPS connection (which implies SSL enveloping) and then alter the connection status to WS, the whole "WS story" appears naturally INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. +> +> Is it true? +> +> In this regard i can hardly find a place in this world for the "WSS" term, what does it stand for? +> +> Please, help me fit it in my head. +> +> However, i might be confusing some Client-Side entities, that are involved in the process of starting up my WebSocket. +> +> I am using a Browser with JavaScript. +> +> The semantics of the very WebSocket.start() operation is not enough clear to me. Please, do not laugh. +> +> when i do JS WebSocket.start() does it: +> (a) opens an http connection and then alters it to WS +> (b) alters the connection in the context of which the JS process is running +> ???? +> +> I'll be damned if the answer was lying on the surface of the internet! +> +> The third part of this ugly question is about cowboy actually. +> How all these entities mentioned above do map into my_app.erl file? +> what particular bits of cowboy's "configuration" (may i call this particular piece of code a "setup" or "config"?) affect what aspects of the connection initialization. +> +> well, i am afraid it could be put in a simpler way: +> "Exactly When and Where the WSS story begins?" +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + + +From e at bestmx.net Sat Jan 10 15:46:23 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 15:46:23 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + + > I use Cowboy for websockets, but I find it?s a lot easier (and less + > stressful) to run Nginx in front of it to provide the SSL layer. + +well, nginx is my choice for almost everything, still i am trying to +minimize amount of intermediate software wherever possible. + +P.S. +with nginx and postgreSQL i have managed to eliminate any trace of +server-side scripting in my previous project :) +just nginx connected to Postgres. + + +From e at bestmx.net Sat Jan 10 16:28:19 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 16:28:19 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +thanx again. +now everything "magically" works :) + + +On 01/10/2015 03:34 PM, Lo?c Hoguin wrote: +> Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter +> I think. +> +> On 01/10/2015 03:28 PM, e at bestmx.net wrote: +>>> In Cowboy, use start_https instead of start_http. +>> +>> thanx! it makes a lot of sense for me. +>> tell me please what deps should be declared in the .app file? +>> +>> is the following correct? +>> +>> {applications, [ +>> kernel, +>> stdlib, +>> crypto, +>> public_key, +>> ssl, +>> cowboy +>> ]}, +>> +>> does the order matters? +>> +>> (i borrowed that from the internet without deep understanding of the +>> roles of each app on the list) +> + +From stefan.strigler at gmail.com Wed Jan 14 17:45:41 2015 +From: stefan.strigler at gmail.com (Stefan Strigler) +Date: Wed, 14 Jan 2015 17:45:41 +0100 +Subject: [99s-extend] cowboy and handling exceptions +Message-ID: <CAE7Uswd9-1g2QytyFPBWTFzy1KKhBircPT6_Q=g_qBNqwnouow@mail.gmail.com> + +Hey there, + +maybe I'm missing the obvious. What I want to do is add some generic +handler for exception handling. Say we have a set of resources some of +which delegating stuff to external, other services. These calls might +result in a + +throw({error, timeout}) + +for instance. How would I add/modify cowboy's middleware (right place?) to +handle those (known) exception and return a custom error (like 504 - +Gateway Timeout). + +Thanks for any hints, + +Steve +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20150114/3267f73e/attachment.html> + +From essen at ninenines.eu Wed Jan 14 18:49:39 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 14 Jan 2015 18:49:39 +0100 +Subject: [99s-extend] cowboy and handling exceptions +In-Reply-To: <CAE7Uswd9-1g2QytyFPBWTFzy1KKhBircPT6_Q=g_qBNqwnouow@mail.gmail.com> +References: <CAE7Uswd9-1g2QytyFPBWTFzy1KKhBircPT6_Q=g_qBNqwnouow@mail.gmail.com> +Message-ID: <[email protected]> + +I don't know, there is no such thing in Cowboy. :-) + +On 01/14/2015 05:45 PM, Stefan Strigler wrote: +> Hey there, +> +> maybe I'm missing the obvious. What I want to do is add some generic +> handler for exception handling. Say we have a set of resources some of +> which delegating stuff to external, other services. These calls might +> result in a +> +> throw({error, timeout}) +> +> for instance. How would I add/modify cowboy's middleware (right place?) +> to handle those (known) exception and return a custom error (like 504 - +> Gateway Timeout). +> +> Thanks for any hints, +> +> Steve +> +> +> _______________________________________________ +> 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 Jan 14 18:50:21 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 14 Jan 2015 18:50:21 +0100 +Subject: [99s-extend] cowboy and handling exceptions +In-Reply-To: <[email protected]> +References: <CAE7Uswd9-1g2QytyFPBWTFzy1KKhBircPT6_Q=g_qBNqwnouow@mail.gmail.com> +Message-ID: <[email protected]> + +I send too early... + +I want to add a hook for when Cowboy receives exceptions in Cowboy 2, so +at that point you will be able to do it. But nothing in current Cowboy. + +On 01/14/2015 06:49 PM, Lo?c Hoguin wrote: +> I don't know, there is no such thing in Cowboy. :-) +> +> On 01/14/2015 05:45 PM, Stefan Strigler wrote: +>> Hey there, +>> +>> maybe I'm missing the obvious. What I want to do is add some generic +>> handler for exception handling. Say we have a set of resources some of +>> which delegating stuff to external, other services. These calls might +>> result in a +>> +>> throw({error, timeout}) +>> +>> for instance. How would I add/modify cowboy's middleware (right place?) +>> to handle those (known) exception and return a custom error (like 504 - +>> Gateway Timeout). +>> +>> Thanks for any hints, +>> +>> Steve +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Mon Jan 19 20:32:00 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Mon, 19 Jan 2015 20:32:00 +0100 +Subject: [99s-extend] Cowboy + SSL +Message-ID: <[email protected]> + +Hello. + +i still have a problem with SSL. +as soon as i change cowboy:start_http call to cowboy:start_https +my release refuses to stop (when requested) +and when i revert to "http" it starts and stops normally. + +i am sure it is the only difference: start_http vs. start_https + +i am using relx with default settings as it was provided by cowboy +(Erlang R17, System: Debian "testing") + +here is my_app.erl: + +start(_Type, _Args) -> + Dispatch = + cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), + + cowboy:start_https( https, 100, [ {port, 8765} + , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} + , {certfile, ?Dir ++ "/ssl/server.crt"} + , {keyfile, ?Dir ++ "/ssl/server.key"} ] + , [{env, [{dispatch, Dispatch}]}]), + + online37_sup:start_link(). + +stop(_State) -> ok. + + +once i call: +release/bin/my_release stop + +the erlang.log repeats hundreds of: + +=ERROR REPORT==== 19-Jan-2015::20:06:02 === +Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +{{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} + + +what could it be? +any misconfiguration of my system (regarding ssl support)? +what exactly does ranch expect from me? + + + +From e at bestmx.net Wed Jan 21 19:28:40 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Wed, 21 Jan 2015 19:28:40 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <[email protected]> + +reading the sources i have found that this crash i am trying to report +is intended behavior, +but +it happens in the middle of the SHUTDOWN procedure! + + +I tried to investigate how a relx's release shuts down +and i have found it is merely one call to: init:stop/0 +nothing else. + +the manual says: + +stop() -> ok + +All applications are taken down smoothly, all code is unloaded, and all +ports are closed before the system terminates. If the -heart command +line flag was given, the heart program is terminated before the Erlang +node terminates. + +I end up totally clueless -- everything is rock solid yet it crashes. +maybe there is some clue in the sequence of shutting down applications? + +does anything controls/defines that sequence? + + + +On 01/19/2015 08:32 PM, e at bestmx.net wrote: +> Hello. +> +> i still have a problem with SSL. +> as soon as i change cowboy:start_http call to cowboy:start_https +> my release refuses to stop (when requested) +> and when i revert to "http" it starts and stops normally. +> +> i am sure it is the only difference: start_http vs. start_https +> +> i am using relx with default settings as it was provided by cowboy +> (Erlang R17, System: Debian "testing") +> +> here is my_app.erl: +> +> start(_Type, _Args) -> +> Dispatch = +> cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), +> +> cowboy:start_https( https, 100, [ {port, 8765} +> , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} +> , {certfile, ?Dir ++ "/ssl/server.crt"} +> , {keyfile, ?Dir ++ "/ssl/server.key"} ] +> , [{env, [{dispatch, Dispatch}]}]), +> +> online37_sup:start_link(). +> +> stop(_State) -> ok. +> +> +> once i call: +> release/bin/my_release stop +> +> the erlang.log repeats hundreds of: +> +> =ERROR REPORT==== 19-Jan-2015::20:06:02 === +> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +> +> +> +> what could it be? +> any misconfiguration of my system (regarding ssl support)? +> what exactly does ranch expect from me? +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +From pdtwonotes at gmail.com Sun Jan 25 23:30:08 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Sun, 25 Jan 2015 17:30:08 -0500 +Subject: [99s-extend] Rewriting URLs +Message-ID: <[email protected]> + +I am trying to write a middleware step that will modify the URL in a +request before it gets to the default static request handler. I can not +find an example of how to do this. What I?have so far: + +execute( Req, Env ) -> + HostUrl = cowboy_req:host_url(Req), + NewUrl = rewrite( HostUrl ), + NewReq = ??? + {ok, NewReq, Env}. + +How do I modify a Request object so that it contains my modified URL, +which cowboy_static will then process normally? My 'rewrite' function +converts logical directory names into real file-system paths, using a +dynamic algorithm that can not be simply written into cowboy's dispatch +rules. + +The dispatch rules I am using is as follows, where 'bz_libmap' is my +module containing the code above: + {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20150125/370811e4/attachment.html> + +From pdtwonotes at gmail.com Mon Jan 26 06:09:49 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Mon, 26 Jan 2015 00:09:49 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> +Message-ID: <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> + +Some progress. I think this is how the code should look in my middleware: + +execute( Req, Env ) -> + HostUrl = cowboy_req:path(Req), + NewUrl = rewrite( HostUrl ), + NewReq = cowboy_req:set( [{path,NewUrl}], Req), + {ok, NewReq, Env}. + +It is getting called, but cowboy_static is being passed the wrong +thing afterward. I think I do not understand how to write the +dispatch rule. The value of NewUrl is an absolute filename. + + {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, + +From essen at ninenines.eu Mon Jan 26 11:26:42 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 26 Jan 2015 11:26:42 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +You have to change path_info too if your middleware is after the router. + +On 01/26/2015 06:09 AM, Paul Dickson wrote: +> Some progress. I think this is how the code should look in my middleware: +> +> execute( Req, Env ) -> +> HostUrl = cowboy_req:path(Req), +> NewUrl = rewrite( HostUrl ), +> NewReq = cowboy_req:set( [{path,NewUrl}], Req), +> {ok, NewReq, Env}. +> +> It is getting called, but cowboy_static is being passed the wrong +> thing afterward. I think I do not understand how to write the +> dispatch rule. The value of NewUrl is an absolute filename. +> +> {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, +> _______________________________________________ +> 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 Jan 26 11:29:34 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 26 Jan 2015 11:29:34 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +Hey, this is a known issue with recent Erlang versions: +https://github.com/ninenines/ranch/issues/90 + +I don't have a good fix for it other than requiring ssl for using +Cowboy/Ranch. I probably will. + +On 01/21/2015 07:28 PM, e at bestmx.net wrote: +> reading the sources i have found that this crash i am trying to report +> is intended behavior, +> but +> it happens in the middle of the SHUTDOWN procedure! +> +> +> I tried to investigate how a relx's release shuts down +> and i have found it is merely one call to: init:stop/0 +> nothing else. +> +> the manual says: +> +> stop() -> ok +> +> All applications are taken down smoothly, all code is unloaded, and all +> ports are closed before the system terminates. If the -heart command +> line flag was given, the heart program is terminated before the Erlang +> node terminates. +> +> I end up totally clueless -- everything is rock solid yet it crashes. +> maybe there is some clue in the sequence of shutting down applications? +> +> does anything controls/defines that sequence? +> +> +> +> On 01/19/2015 08:32 PM, e at bestmx.net wrote: +>> Hello. +>> +>> i still have a problem with SSL. +>> as soon as i change cowboy:start_http call to cowboy:start_https +>> my release refuses to stop (when requested) +>> and when i revert to "http" it starts and stops normally. +>> +>> i am sure it is the only difference: start_http vs. start_https +>> +>> i am using relx with default settings as it was provided by cowboy +>> (Erlang R17, System: Debian "testing") +>> +>> here is my_app.erl: +>> +>> start(_Type, _Args) -> +>> Dispatch = +>> cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), +>> +>> cowboy:start_https( https, 100, [ {port, 8765} +>> , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} +>> , {certfile, ?Dir ++ "/ssl/server.crt"} +>> , {keyfile, ?Dir ++ "/ssl/server.key"} ] +>> , [{env, [{dispatch, Dispatch}]}]), +>> +>> online37_sup:start_link(). +>> +>> stop(_State) -> ok. +>> +>> +>> once i call: +>> release/bin/my_release stop +>> +>> the erlang.log repeats hundreds of: +>> +>> =ERROR REPORT==== 19-Jan-2015::20:06:02 === +>> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +>> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +>> +>> +>> +>> +>> what could it be? +>> any misconfiguration of my system (regarding ssl support)? +>> what exactly does ranch expect from me? +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Mon Jan 26 15:30:56 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Mon, 26 Jan 2015 15:30:56 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <[email protected]> +References: <[email protected]> <[email protected]> +Message-ID: <[email protected]> + +> Hey, this is a known issue with recent Erlang versions: +> https://github.com/ninenines/ranch/issues/90 + +sorry i didn't know a keyword for googling this issue + +well, it seems to me very interesting problem -- basically a dependency +that appears in runtime (if i do not pass an ssl socket to the ranch, +there will be no dependency). + +i dare to suggest few alternative approaches to the solution: + +(A) make the shutdown state distinguishable for the 'ranch_acceptor', so +that not to crash in one particular sub case of the preliminary socket +close. (a terrible STATEFUL solution, i do not dare to suggest how to +pass this state to the acceptor) + +(B) make it possible *in general* to pass additional dependencies to the +applications that your application depends on. (as for now i can define +in my .app.src any arbitrary deps for the "top" application, and then +this .app.src will be processed anyway, there is no harm in improving +this .app preparation procedure one step further, in order to affect +.app files of subordinate applications. (it is perhaps a suggestion for +relx devs, anyway, nobody forbid us to discuss it)) + +there are some alternative ways to achieve (B) + +(B1) +it would be a mere change of the type of the 'applications' option in +.app.src -- we may make it a tree instead of a list. +for example: + +{applications, [ + kernel, + stdlib, + mnesia, + {cowboy, [{ranch, [ssl]}]} +]} +%% which reads: my app requires all these, +%% and cowboy must require ranch and ranch must require ssl + +it could (or should?) be shortened to: + +(B2) +%% my app requires all these, +%% and *IF* 'ranch' is somehow required then it must require ssl +{applications, [ + kernel, + stdlib, + mnesia, + cowboy, + {ranch, [ssl]} +]} + +this in turn makes separation possible: + +(B3) +we specify all applications we require as a plain list, and then we +specify PARTIAL ORDER: we need some certain pairs of applications to be +started in certain sequences. + +{applications, [ + kernel, + stdlib, + mnesia, + ssl, + cowboy +]}, +{sequence, [ + [ssl, ranch], +]} + +%% which reads: my app requires those apps to start +%% and among these it requires the ssl to be started BEFORE ranch + +%% generally we may specify any amount +%% of subsequences we care about: +{sequence, [ + [ssl, ranch], + [ranch, cowboy_lib, cowboy], + [appA1, appA2, appA3, ...], + ... +]} + +of course the specified sequence MIGHT BE IMPOSSIBLE (self-refuting) and +it needs to be verified, which is formally possible. + +From pdtwonotes at gmail.com Mon Jan 26 22:54:09 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Mon, 26 Jan 2015 16:54:09 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +> You have to change path_info too if your middleware is after the router. +> +I have added that. My cowboy:start_http parameters include this: + {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +which I think means bz_libmap will get called on *every* request. This +seems to work. Among the dispatch rules is this line: + {"/music/[...]", cowboy_static, {dir, "", ""}}, +so any request starting with "/music/ will do a standard file fetch. +But due to the middlewares setup, bz_libmap will get a chance to +look at it first. + +bz_libmap checks the path to see if it starts with "/music/", and if +not, it just returns {ok,Req,Env} and lets processing proceed normally. +This works, and other dispatch rules take care of it, usually fetching +files from priv_dir. + +But if bz_libmap sees "/music/" at the start of the URL it transforms +the URL into something else, an absolute filename typically of an mp3 +file. This is what I want cowboy_static to process. Hopefully, this +does not run through the dispatch rules again. + +bz_libmap computes a new path and a new path_info and sets them with a +cowboy_req:set call. I am not sure what path_info should look like at +this point, because the path is no longer covered by any of the dispatch +rules. I do not want it to be, as that would allow a browser to fetch +any file in the file system, unchecked. + +But what happens is any attempts to fetch /music/Anything result in a +status 400 error. + +The other approach I was considering was to make my own handler, based +on cowboy_static, that does the URL/File transformation internally. But +even that might not be right, since it eventually upgrades to +cowboy_rest and there is more processing after that. This approach +seems inelegant. + +The actual only call to file:open I found in all of cowboy is in +cowboy_spdy. + + + + +From essen at ninenines.eu Tue Jan 27 11:13:41 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 11:13:41 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On 01/26/2015 10:54 PM, Paul Dickson wrote: +> On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +>> You have to change path_info too if your middleware is after the router. +>> +> I have added that. My cowboy:start_http parameters include this: +> {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +> which I think means bz_libmap will get called on *every* request. This +> seems to work. Among the dispatch rules is this line: +> {"/music/[...]", cowboy_static, {dir, "", ""}}, + +Is it the actual line? Cause {dir, "", ""} is wrong, the third element +must be an etag or mimetype tuple. + +Otherwise, I need a more complete error, or code. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:07:48 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:07:48 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On Tue, 2015-01-27 at 11:13 +0100, Lo?c Hoguin wrote: +> On 01/26/2015 10:54 PM, Paul Dickson wrote: +> > On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +> >> You have to change path_info too if your middleware is after the router. +> >> +> > I have added that. My cowboy:start_http parameters include this: +> > {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +> > which I think means bz_libmap will get called on *every* request. This +> > seems to work. Among the dispatch rules is this line: +> > {"/music/[...]", cowboy_static, {dir, "", ""}}, +> +> Is it the actual line? Cause {dir, "", ""} is wrong, the third element +> must be an etag or mimetype tuple. +> +> Otherwise, I need a more complete error, or code. + +I changed the rule line to: + + {"/music/[...]", cowboy_static, {dir, "", [ + {mimetypes, cow_mimetypes, all}]}}, + +The client I am using is 'mplayer'. The error message is: + + Server returned 400:Bad Request + Failed to parse header. + Failed, exiting. + +I also included some tracing in my middleware module to print +out the new path and path_info values it is setting, showing +the result of the rewrite algorithm. + + Path <<"/music/Library/Folk/Swiss/Alphorn.ogg">> + Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, + <<"Alphorn.ogg">>] + + + +From essen at ninenines.eu Tue Jan 27 14:10:58 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 14:10:58 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On 01/27/2015 02:07 PM, Paul Dickson wrote: +> Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +> <<"Alphorn.ogg">>] + +Should be from Library onward, and not include the first two elements. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:24:30 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:24:30 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On Tue, 2015-01-27 at 14:10 +0100, Lo?c Hoguin wrote: + +> On 01/27/2015 02:07 PM, Paul Dickson wrote: +> > Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +> > <<"Alphorn.ogg">>] +> +> Should be from Library onward, and not include the first two elements. +> + + +This is perhaps a confusing case, because the incoming URL and the +transformed URL both start with "/music". What if that was not the +case, and the resulting path was, for example, + + /home/me/music/Folk/Swiss/Alphorn.ogg + +which does not match anything in the rules at all? Is that allowed, or +must the rewritten URL also match a rule? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: <http://lists.ninenines.eu/archives/extend/attachments/20150127/1916d612/attachment.html> + +From essen at ninenines.eu Tue Jan 27 14:29:20 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 14:29:20 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +On 01/27/2015 02:24 PM, Paul Dickson wrote: +> On Tue, 2015-01-27 at 14:10 +0100, Lo?c Hoguin wrote: +>> On 01/27/2015 02:07 PM, Paul Dickson wrote: +>> > Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +>> > <<"Alphorn.ogg">>] +>> +>> Should be from Library onward, and not include the first two elements. +>> +> +> This is perhaps a confusing case, because the incoming URL and the +> transformed URL both start with "/music". What if that was not the +> case, and the resulting path was, for example, +> +> /home/me/music/Folk/Swiss/Alphorn.ogg +> +> which does not match anything in the rules at all? Is that allowed, or +> must the rewritten URL also match a rule? + +Middlewares execute in order and only once, so not sure what you're asking. + +Again I'd need to see some code to help you as I am quite confused by +what you are trying to do and what your issue is. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:44:14 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:44:14 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <[email protected]> + +Ok, here is all the code in bz_libmap.erl + +execute(Req, Env) -> + Path = cowboy_req:path(Req), + Parts = filename:split(Path), + + case cowboy_req:method(Req) of + <<"GET">> -> + % Check for "/music/" requests + rewrite( Parts, Req, Env ); + _Other -> + {ok, Req, Env} + end. + +rewrite( [<<"/">>, <<"music">>, LibName | UrlParts], Req, Env ) -> + % We want URLs of the form "/music/LIBNAME/everythingelse" + % Get library definition. If we do not know that name, then they + % are asking for something that does not exist. + case bz_db:get_library( LibName ) of + [] -> + io:format("No such library '~s'~n", [LibName] ), + {stop, cowboy_req:reply(404, Req)}; + + L when is_record(L,library) -> + % Replace the library name with the library base. + % This will be the head of an absolute file path. + LibBase = L#library.base, + NewPath = filename:join([LibBase | UrlParts]), + NewInfo = filename:split(NewPath), + Req2 = cowboy_req:set( [ + {path_info,[NewPath]}, + {path, [NewPath]}], Req), + {ok, Req2, Env} + end; +rewrite( _AnythingElse, Req, Env ) -> + {ok, Req, Env}. + + + + +From pdtwonotes at gmail.com Thu Jan 29 23:23:35 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Thu, 29 Jan 2015 17:23:35 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <[email protected]> +References: <[email protected]> + <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> +Message-ID: <CAOdRa2Z-13J_0uGtKYBjXvmiyX0bCnNXbCAxRmkr4RkgyrhDJA@mail.gmail.com> + +The status 400 is coming from cowboy_rest, when it complains that +handler cowboy_static lacks the functions 'service_available', +'known_methods', 'uri_too_long', and 'allowed_methods'. Which indeed +it does not have. + +The only place I mention cowboy_static is in the dispatch rule: + {"/music/[...]", cowboy_static, {dir, "", [ + {mimetypes, cow_mimetypes, all}]}}, + +From essen at ninenines.eu Thu Jan 29 23:24:59 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 29 Jan 2015 23:24:59 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <CAOdRa2Z-13J_0uGtKYBjXvmiyX0bCnNXbCAxRmkr4RkgyrhDJA@mail.gmail.com> +References: <[email protected]> <CAOdRa2a5+57KeT3xWwabFxoWSMU8yysqVZvQFVQVVL-FJCAz4w@mail.gmail.com> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> + <CAOdRa2Z-13J_0uGtKYBjXvmiyX0bCnNXbCAxRmkr4RkgyrhDJA@mail.gmail.com> +Message-ID: <[email protected]> + +They are optional callbacks, so I doubt that's it. + +On 01/29/2015 11:23 PM, Paul Dickson wrote: +> The status 400 is coming from cowboy_rest, when it complains that +> handler cowboy_static lacks the functions 'service_available', +> 'known_methods', 'uri_too_long', and 'allowed_methods'. Which indeed +> it does not have. +> +> The only place I mention cowboy_static is in the dispatch rule: +> {"/music/[...]", cowboy_static, {dir, "", [ +> {mimetypes, cow_mimetypes, all}]}}, +> + +-- +Lo?c Hoguin +http://ninenines.eu + |