Add old mailing list archives

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]>
+ <[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]>
+ <[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]>
+ <[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>
+ <[email protected]>
+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]>
+ <[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>
+ <[email protected]>
+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>	
+ <[email protected]> <[email protected]>
+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>
+ <[email protected]> <[email protected]>
+ <[email protected]>
+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>		
+ <[email protected]> <[email protected]>	
+ <[email protected]> <[email protected]>
+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>
+ <[email protected]> <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]>
+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>			
+ <[email protected]> <[email protected]>		
+ <[email protected]> <[email protected]>	
+ <[email protected]> <[email protected]>
+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>
+ <[email protected]> <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]> <[email protected]>
+ <[email protected]>
+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>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+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
+