Add old mailing list archives

1 files changed, 545 insertions, 0 deletions

diff --git a/archives/extend/2014-July.txt b/archives/extend/2014-July.txt
new file mode 100644
index 00000000..c6ff98a3
--- /dev/null
+++ b/archives/extend/2014-July.txt
@@ -0,0 +1,545 @@
+From adelzhang at qq.com  Thu Jul  3 09:40:12 2014
+From: adelzhang at qq.com (Adel Zhang)
+Date: Thu, 03 Jul 2014 15:40:12 +0800
+Subject: [99s-extend] tring to understand ranch_conns_sup
+Message-ID: <op.xievlal52w9y7f@zgc-201309221420>
+
+Ranch uses a tcp acceptor pool to accept connections concurrently. But the  
+acceptor process
+needs to wait for the *only one* ranch_conns_sup spawning the protocol  
+process.
+
+Is ranch_conns_sup maybe a bottleneck?
+
+Thanks.
+
+From essen at ninenines.eu  Thu Jul  3 09:55:13 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Thu, 03 Jul 2014 09:55:13 +0200
+Subject: [99s-extend] tring to understand ranch_conns_sup
+In-Reply-To: <op.xievlal52w9y7f@zgc-201309221420>
+References: <op.xievlal52w9y7f@zgc-201309221420>
+Message-ID: <[email protected]>
+
+Have you observed ranch_conns_sup be a bottleneck? In practice it 
+shouldn't be.
+
+On 07/03/2014 09:40 AM, Adel Zhang wrote:
+> Ranch uses a tcp acceptor pool to accept connections concurrently. But
+> the acceptor process
+> needs to wait for the *only one* ranch_conns_sup spawning the protocol
+> process.
+>
+> Is ranch_conns_sup maybe a bottleneck?
+>
+> Thanks.
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+From samuelrivas at gmail.com  Tue Jul  8 09:12:43 2014
+From: samuelrivas at gmail.com (Samuel)
+Date: Tue, 8 Jul 2014 09:12:43 +0200
+Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT
+Message-ID: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+
+Hi,
+
+According to the documentation I should be able to return a new
+location when handling a PUT request when using cowboy_rest protocol:
+
+    The AcceptResource value is the name of the callback that will be
+called if the
+    content-type matches. It is defined as follow.
+
+    Value type: true | {true, URL} | false
+
+That works for "true" and "false" but not for "{true, URL}", in that
+case the Ranch listener crashes badly[1].
+
+Looking into cowboy_rest.erl I see that the {true, URL} form is
+restricted to POST requests:
+https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+
+Is that intentional or should I submit a patch to add at least PUT and
+PATCH to that condition (or remove all of them if that is not guarding
+against something horrible)?
+
+Regards
+
+[1] Ranch crash log:
+Ranch listener http_acceptor had connection process started with
+cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+{{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+(x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+-- 
+Samuel
+
+From essen at ninenines.eu  Tue Jul  8 11:57:12 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Tue, 08 Jul 2014 11:57:12 +0200
+Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT
+In-Reply-To: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+References: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+Message-ID: <[email protected]>
+
+It's not enabled for PATCH or PUT because it makes little sense for 
+them. PATCH and PUT are typically used directly on the URI of the 
+resource, even when creating it. While you can return a "better URI" for 
+the created resource for them, this should be seen as a special case 
+rather than the norm. You can still do it by setting the location header 
+manually and Cowboy will react accordingly.
+
+On 07/08/2014 09:12 AM, Samuel wrote:
+> Hi,
+>
+> According to the documentation I should be able to return a new
+> location when handling a PUT request when using cowboy_rest protocol:
+>
+>      The AcceptResource value is the name of the callback that will be
+> called if the
+>      content-type matches. It is defined as follow.
+>
+>      Value type: true | {true, URL} | false
+>
+> That works for "true" and "false" but not for "{true, URL}", in that
+> case the Ranch listener crashes badly[1].
+>
+> Looking into cowboy_rest.erl I see that the {true, URL} form is
+> restricted to POST requests:
+> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>
+> Is that intentional or should I submit a patch to add at least PUT and
+> PATCH to that condition (or remove all of them if that is not guarding
+> against something horrible)?
+>
+> Regards
+>
+> [1] Ranch crash log:
+> Ranch listener http_acceptor had connection process started with
+> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+> libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+From samuelrivas at gmail.com  Tue Jul  8 13:32:45 2014
+From: samuelrivas at gmail.com (Samuel)
+Date: Tue, 8 Jul 2014 13:32:45 +0200
+Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT
+In-Reply-To: <[email protected]>
+References: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAH2nEUi9qkU4tjeYMNzQeppJ4me3p3z2UPqfSB-dQ6G4x_ExyA@mail.gmail.com>
+
+Ok, thanks. That should probably be mentioned in the documentation of
+content_types_accepted, as it says {true, URI} is a valid output for
+the provided function.
+
+Just out of curiosity from a non-so-expert in REST. The API spec
+(which I am not the author of) says the PUT call should create a
+resource with a unique id and return the URI of the created resource
+in the Location header. That is something like PUT /some/resource
+should return /some/resource/1234 in the Location. some/resource is
+fixed but 1234 would be generated for each instance of /some/resource.
+Is that considered nonsensical?
+
+On 8 July 2014 11:57, Lo?c Hoguin <essen at ninenines.eu> wrote:
+> It's not enabled for PATCH or PUT because it makes little sense for them.
+> PATCH and PUT are typically used directly on the URI of the resource, even
+> when creating it. While you can return a "better URI" for the created
+> resource for them, this should be seen as a special case rather than the
+> norm. You can still do it by setting the location header manually and Cowboy
+> will react accordingly.
+>
+>
+> On 07/08/2014 09:12 AM, Samuel wrote:
+>>
+>> Hi,
+>>
+>> According to the documentation I should be able to return a new
+>> location when handling a PUT request when using cowboy_rest protocol:
+>>
+>>      The AcceptResource value is the name of the callback that will be
+>> called if the
+>>      content-type matches. It is defined as follow.
+>>
+>>      Value type: true | {true, URL} | false
+>>
+>> That works for "true" and "false" but not for "{true, URL}", in that
+>> case the Ranch listener crashes badly[1].
+>>
+>> Looking into cowboy_rest.erl I see that the {true, URL} form is
+>> restricted to POST requests:
+>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>>
+>> Is that intentional or should I submit a patch to add at least PUT and
+>> PATCH to that condition (or remove all of them if that is not guarding
+>> against something horrible)?
+>>
+>> Regards
+>>
+>> [1] Ranch crash log:
+>> Ranch listener http_acceptor had connection process started with
+>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+>>
+>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+>> libidn/1.23
+>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>>
+>
+> --
+> Lo?c Hoguin
+> http://ninenines.eu
+
+
+
+-- 
+Samuel
+
+From essen at ninenines.eu  Tue Jul  8 13:42:00 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Tue, 08 Jul 2014 13:42:00 +0200
+Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT
+In-Reply-To: <CAH2nEUi9qkU4tjeYMNzQeppJ4me3p3z2UPqfSB-dQ6G4x_ExyA@mail.gmail.com>
+References: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+ <[email protected]>
+ <CAH2nEUi9qkU4tjeYMNzQeppJ4me3p3z2UPqfSB-dQ6G4x_ExyA@mail.gmail.com>
+Message-ID: <[email protected]>
+
+That's what POST should do.
+
+Compare:
+
+PUT /some/resource/1234 -> no redirect needed
+POST /some/resource -> creates /some/resource/1234, redirects
+
+If /some/resource is a collection then PUT on that collection is 
+supposed to replace it entirely.
+
+Again it's possible for PUT to create a resource elsewhere, but 
+typically the redirect would be from something like 
+http://api.yourservice.com/resource/1234 to 
+http://cloudthingy.server137.yourservice.com/whatever/resource/1234 and 
+not to do what POST is intended for.
+
+On 07/08/2014 01:32 PM, Samuel wrote:
+> Ok, thanks. That should probably be mentioned in the documentation of
+> content_types_accepted, as it says {true, URI} is a valid output for
+> the provided function.
+>
+> Just out of curiosity from a non-so-expert in REST. The API spec
+> (which I am not the author of) says the PUT call should create a
+> resource with a unique id and return the URI of the created resource
+> in the Location header. That is something like PUT /some/resource
+> should return /some/resource/1234 in the Location. some/resource is
+> fixed but 1234 would be generated for each instance of /some/resource.
+> Is that considered nonsensical?
+>
+> On 8 July 2014 11:57, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>> It's not enabled for PATCH or PUT because it makes little sense for them.
+>> PATCH and PUT are typically used directly on the URI of the resource, even
+>> when creating it. While you can return a "better URI" for the created
+>> resource for them, this should be seen as a special case rather than the
+>> norm. You can still do it by setting the location header manually and Cowboy
+>> will react accordingly.
+>>
+>>
+>> On 07/08/2014 09:12 AM, Samuel wrote:
+>>>
+>>> Hi,
+>>>
+>>> According to the documentation I should be able to return a new
+>>> location when handling a PUT request when using cowboy_rest protocol:
+>>>
+>>>       The AcceptResource value is the name of the callback that will be
+>>> called if the
+>>>       content-type matches. It is defined as follow.
+>>>
+>>>       Value type: true | {true, URL} | false
+>>>
+>>> That works for "true" and "false" but not for "{true, URL}", in that
+>>> case the Ranch listener crashes badly[1].
+>>>
+>>> Looking into cowboy_rest.erl I see that the {true, URL} form is
+>>> restricted to POST requests:
+>>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>>>
+>>> Is that intentional or should I submit a patch to add at least PUT and
+>>> PATCH to that condition (or remove all of them if that is not guarding
+>>> against something horrible)?
+>>>
+>>> Regards
+>>>
+>>> [1] Ranch crash log:
+>>> Ranch listener http_acceptor had connection process started with
+>>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+>>>
+>>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+>>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+>>> libidn/1.23
+>>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>>>
+>>
+>> --
+>> Lo?c Hoguin
+>> http://ninenines.eu
+>
+>
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+From samuelrivas at gmail.com  Tue Jul  8 13:49:35 2014
+From: samuelrivas at gmail.com (Samuel)
+Date: Tue, 8 Jul 2014 13:49:35 +0200
+Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT
+In-Reply-To: <[email protected]>
+References: <CAH2nEUgJj1f8_RnXqeKqB1tFaDh=qzztOo9XF94S9auQ93dskg@mail.gmail.com>
+ <[email protected]>
+ <CAH2nEUi9qkU4tjeYMNzQeppJ4me3p3z2UPqfSB-dQ6G4x_ExyA@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAH2nEUhEWO8AOHBa6WJJaN6jch5FzASAq7NUyQG3U9b4dKeTow@mail.gmail.com>
+
+> Compare:
+>
+> PUT /some/resource/1234 -> no redirect needed
+> POST /some/resource -> creates /some/resource/1234, redirects
+>
+> If /some/resource is a collection then PUT on that collection is supposed to
+> replace it entirely.
+
+Great, thanks for the explanation. I'll try to discuss that with the
+authors of the API
+
+-- 
+Samuel
+
+From paulo.ferraz.oliveira at gmail.com  Tue Jul  8 15:17:32 2014
+From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira)
+Date: Tue, 8 Jul 2014 14:17:32 +0100
+Subject: [99s-extend] HTTP Basic Auth base64 decode fails
+Message-ID: <CA+dV7cS+1dfOHFZrMyognVSbVEdX45Rf264ndo0N8nCb1BmnmA@mail.gmail.com>
+
+Hello, y'all.
+
+I'm using HTTP Basic Auth in my API. While calling
+cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+Authorization header such as "Authorization: Basic Test1" I get an error
+500 back and an error log message on the server.
+
+1. Is this the expected behavior? [if I understand correctly, my request is
+going through authorization(UserPass, Type = <<"basic">>) and this has no
+check for the string being correctly encoded]
+
+2. what would be the best way to guard against this "error"?
+
+Thanks.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140708/35d8806d/attachment.html>
+
+From essen at ninenines.eu  Tue Jul  8 15:21:28 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Tue, 08 Jul 2014 15:21:28 +0200
+Subject: [99s-extend] HTTP Basic Auth base64 decode fails
+In-Reply-To: <CA+dV7cS+1dfOHFZrMyognVSbVEdX45Rf264ndo0N8nCb1BmnmA@mail.gmail.com>
+References: <CA+dV7cS+1dfOHFZrMyognVSbVEdX45Rf264ndo0N8nCb1BmnmA@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Parsing of any header may crash. Some may also return an error tuple, 
+though that behavior slowly changes and it will always crash in 2.0. So 
+just wrap the call around a try/catch if you need to handle the error.
+
+Note that at this exact moment I'm working on returning 400 instead of 
+500 automatically when parsing headers end up crashing (and possibly 
+other situations later on).
+
+On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote:
+> Hello, y'all.
+>
+> I'm using HTTP Basic Auth in my API. While calling
+> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+> Authorization header such as "Authorization: Basic Test1" I get an error
+> 500 back and an error log message on the server.
+>
+> 1. Is this the expected behavior? [if I understand correctly, my request
+> is going through authorization(UserPass, Type = <<"basic">>) and this
+> has no check for the string being correctly encoded]
+>
+> 2. what would be the best way to guard against this "error"?
+>
+> Thanks.
+>
+> - Paulo F. Oliveira
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+
+From paulo.ferraz.oliveira at gmail.com  Tue Jul  8 15:25:58 2014
+From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira)
+Date: Tue, 8 Jul 2014 14:25:58 +0100
+Subject: [99s-extend] HTTP Basic Auth base64 decode fails
+In-Reply-To: <[email protected]>
+References: <CA+dV7cS+1dfOHFZrMyognVSbVEdX45Rf264ndo0N8nCb1BmnmA@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+dV7cRxf-uKJKx-xPhKcm6TXXKLc4H3OVOC2GVQy58V5nASzg@mail.gmail.com>
+
+Great, thanks.
+
+I saw some changes "from 422 to 400" in recent versions (PUT and POST).
+Thanks for the heads up. As long as they're document, no harm shall come of
+these changes.
+
+In any case, if I see it happen very often live I'll "protect" it agains
+the _bad_ header :-).
+
+Cheers.
+
+- Paulo F. Oliveira
+
+
+On 8 July 2014 14:21, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> Parsing of any header may crash. Some may also return an error tuple,
+> though that behavior slowly changes and it will always crash in 2.0. So
+> just wrap the call around a try/catch if you need to handle the error.
+>
+> Note that at this exact moment I'm working on returning 400 instead of 500
+> automatically when parsing headers end up crashing (and possibly other
+> situations later on).
+>
+>
+> On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote:
+>
+>> Hello, y'all.
+>>
+>> I'm using HTTP Basic Auth in my API. While calling
+>> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+>> Authorization header such as "Authorization: Basic Test1" I get an error
+>> 500 back and an error log message on the server.
+>>
+>> 1. Is this the expected behavior? [if I understand correctly, my request
+>> is going through authorization(UserPass, Type = <<"basic">>) and this
+>> has no check for the string being correctly encoded]
+>>
+>> 2. what would be the best way to guard against this "error"?
+>>
+>> Thanks.
+>>
+>> - Paulo F. Oliveira
+>>
+>>
+>> _______________________________________________
+>> 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/20140708/497ef9a1/attachment.html>
+
+From chaehb at gmail.com  Sat Jul 26 09:06:15 2014
+From: chaehb at gmail.com (chaehb)
+Date: Sat, 26 Jul 2014 16:06:15 +0900
+Subject: [99s-extend] couldn't quit in Erlang 17.1
+Message-ID: <[email protected]>
+
+Hi, everybody.
+
+After Erlang updated to 17.1,
+when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages..
+
+(after ok signal printed)
+
+?...
+=ERROR REPORT==== 26-Jul-2014::15:23:33 ===
+Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+?.
+
+Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments.
+
+This is only appeared when I only use ssl(https).
+But when use only http with same dispatch rules, cowboy normally quitted.
+
+What?s wrong? or Normal ?
+
+my environment : 
+OS : Mac OS X Mavricks
+Erlang/OTP : 17.1 from Homebrew
+release tool : relx
+Cowboy and others : latest 
+
+From essen at ninenines.eu  Sun Jul 27 11:25:50 2014
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Sun, 27 Jul 2014 11:25:50 +0200
+Subject: [99s-extend] couldn't quit in Erlang 17.1
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+Does it happen with ssl_hello_world?
+
+On 07/26/2014 09:06 AM, chaehb wrote:
+> Hi, everybody.
+>
+> After Erlang updated to 17.1,
+> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages..
+>
+> (after ok signal printed)
+>
+> ?...
+> =ERROR REPORT==== 26-Jul-2014::15:23:33 ===
+> Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+> ?.
+>
+> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments.
+>
+> This is only appeared when I only use ssl(https).
+> But when use only http with same dispatch rules, cowboy normally quitted.
+>
+> What?s wrong? or Normal ?
+>
+> my environment :
+> OS : Mac OS X Mavricks
+> Erlang/OTP : 17.1 from Homebrew
+> release tool : relx
+> Cowboy and others : latest
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Lo?c Hoguin
+http://ninenines.eu
+