Add old mailing list archives

1 files changed, 2737 insertions, 0 deletions

diff --git a/archives/extend/2013-October.txt b/archives/extend/2013-October.txt
new file mode 100644
index 00000000..4a9176a4
--- /dev/null
+++ b/archives/extend/2013-October.txt
@@ -0,0 +1,2737 @@
+From marcel.meyer at gmail.com  Thu Oct  3 07:00:28 2013
+From: marcel.meyer at gmail.com (Marcel Meyer)
+Date: Wed, 2 Oct 2013 22:00:28 -0700
+Subject: [99s-extend] websocket_info and RPC
+Message-ID: <CAFXVr=ZuQNiChQGFHVcS4jGOHXG5NEazbZcP8qp5E91smJEN1A@mail.gmail.com>
+
+Hi there,
+
+How do I use the websocket infrastructure of cowboy to implement RPC?
+It seems like I can talk to the client using websocket_info, but the
+response comes in on websocket_handle, all asynchronously.
+
+Kind regards,
+Marcel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131002/4463e3fa/attachment.html>
+
+From ryankbrown at gmail.com  Tue Oct  8 05:55:57 2013
+From: ryankbrown at gmail.com (Ryan Brown)
+Date: Mon, 7 Oct 2013 21:55:57 -0600
+Subject: [99s-extend] Problem with cowboy ssl example
+Message-ID: <CAChGYf-ykW7HRb6Hoy6h1NHxmUrbfZ+NBsubvrW-pMieFhESkg@mail.gmail.com>
+
+I was trying to compile and run the ssl_hello_world example in the cowboy
+project and am getting the following error at start-up:
+
+=INFO REPORT==== 7-Oct-2013::21:38:01 ===    application: ssl_hello_world
+  exited: {bad_return,             {{ssl_hello_world_app,start,[normal,[]]},
+            {'EXIT',               {{badmatch,                 {error,
+            {{shutdown,
+{failed_to_start_child,ranch_acceptors_sup,
+ {{case_clause,                       {error,{"no such file or
+directory","asn1.app"}}},
+[{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]},
+
+I can start asn1 from the erl console so I am not sure what I am missing.
+Any help is greatly appreciated.
+
+Best regards.
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131007/fdef2170/attachment.html>
+
+From essen at ninenines.eu  Tue Oct  8 06:13:04 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 08 Oct 2013 06:13:04 +0200
+Subject: [99s-extend] Problem with cowboy ssl example
+In-Reply-To: <CAChGYf-ykW7HRb6Hoy6h1NHxmUrbfZ+NBsubvrW-pMieFhESkg@mail.gmail.com>
+References: <CAChGYf-ykW7HRb6Hoy6h1NHxmUrbfZ+NBsubvrW-pMieFhESkg@mail.gmail.com>
+Message-ID: <[email protected]>
+
+I'm guessing you run an older Erlang which had that issue. Either 
+upgrade Erlang or add asn1 to the list of apps to include in the release 
+(and open a ticket for it please so it can be made to work with older 
+versions).
+
+On 10/08/2013 05:55 AM, Ryan Brown wrote:
+> I was trying to compile and run the ssl_hello_world example in the
+> cowboy project and am getting the following error at start-up:
+>
+>
+>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>
+>
+>        application: ssl_hello_world
+>
+>
+>        exited: {bad_return,
+>
+>
+>                 {{ssl_hello_world_app,start,[normal,[]]},
+>
+>
+>                  {'EXIT',
+>
+>
+>                   {{badmatch,
+>
+>
+>                     {error,
+>
+>
+>                      {{shutdown,
+>
+>
+>                        {failed_to_start_child,ranch_acceptors_sup,
+>
+>
+>                         {{case_clause,
+>
+>
+>                           {error,{"no such file or directory","asn1.app"}}},
+>
+>
+>
+>   [{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]},
+>
+>
+> I can start asn1 from the erl console so I am not sure what I am
+> missing. Any help is greatly appreciated.
+>
+> Best regards.
+>
+> --
+> -rb
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From ryankbrown at gmail.com  Tue Oct  8 06:24:54 2013
+From: ryankbrown at gmail.com (Ryan Brown)
+Date: Mon, 7 Oct 2013 22:24:54 -0600
+Subject: [99s-extend] Problem with cowboy ssl example
+In-Reply-To: <[email protected]>
+References: <CAChGYf-ykW7HRb6Hoy6h1NHxmUrbfZ+NBsubvrW-pMieFhESkg@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAChGYf-krBbQYAkxMuGt-byPV6PSC-50yrOgBMqUJrQBUZeKcA@mail.gmail.com>
+
+Thanks Lo?c. I am actually running R16B on a macbook OS X 10.8. (I'm
+wondering if the Od could have any effect?)
+
+Best,
+
+Ryan
+
+
+On Mon, Oct 7, 2013 at 10:13 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> I'm guessing you run an older Erlang which had that issue. Either upgrade
+> Erlang or add asn1 to the list of apps to include in the release (and open
+> a ticket for it please so it can be made to work with older versions).
+>
+>
+> On 10/08/2013 05:55 AM, Ryan Brown wrote:
+>
+>> I was trying to compile and run the ssl_hello_world example in the
+>> cowboy project and am getting the following error at start-up:
+>>
+>>
+>>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>>
+>>
+>>        application: ssl_hello_world
+>>
+>>
+>>        exited: {bad_return,
+>>
+>>
+>>                 {{ssl_hello_world_app,start,[**normal,[]]},
+>>
+>>
+>>                  {'EXIT',
+>>
+>>
+>>                   {{badmatch,
+>>
+>>
+>>                     {error,
+>>
+>>
+>>                      {{shutdown,
+>>
+>>
+>>                        {failed_to_start_child,ranch_**acceptors_sup,
+>>
+>>
+>>                         {{case_clause,
+>>
+>>
+>>                           {error,{"no such file or
+>> directory","asn1.app"}}},
+>>
+>>
+>>
+>>   [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]},
+>>
+>>
+>> I can start asn1 from the erl console so I am not sure what I am
+>> missing. Any help is greatly appreciated.
+>>
+>> Best regards.
+>>
+>> --
+>> -rb
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+
+
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131007/863e7358/attachment.html>
+
+From ryankbrown at gmail.com  Tue Oct  8 17:33:36 2013
+From: ryankbrown at gmail.com (Ryan Brown)
+Date: Tue, 8 Oct 2013 09:33:36 -0600
+Subject: [99s-extend] Problem with cowboy ssl example
+In-Reply-To: <CAChGYf-krBbQYAkxMuGt-byPV6PSC-50yrOgBMqUJrQBUZeKcA@mail.gmail.com>
+References: <CAChGYf-ykW7HRb6Hoy6h1NHxmUrbfZ+NBsubvrW-pMieFhESkg@mail.gmail.com>
+ <[email protected]>
+ <CAChGYf-krBbQYAkxMuGt-byPV6PSC-50yrOgBMqUJrQBUZeKcA@mail.gmail.com>
+Message-ID: <CAChGYf95Zp7gwj3dxtcw1vU-9wWce6PwA2Z2KJjCPU3jan43eA@mail.gmail.com>
+
+Just to complete the loop. As would be expected, adding asn1 to the app.src
+applications fixes the issue.
+
+Thank you,
+
+Ryan
+
+
+On Mon, Oct 7, 2013 at 10:24 PM, Ryan Brown <ryankbrown at gmail.com> wrote:
+
+> Thanks Lo?c. I am actually running R16B on a macbook OS X 10.8. (I'm
+> wondering if the Od could have any effect?)
+>
+> Best,
+>
+> Ryan
+>
+>
+> On Mon, Oct 7, 2013 at 10:13 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>
+>> I'm guessing you run an older Erlang which had that issue. Either upgrade
+>> Erlang or add asn1 to the list of apps to include in the release (and open
+>> a ticket for it please so it can be made to work with older versions).
+>>
+>>
+>> On 10/08/2013 05:55 AM, Ryan Brown wrote:
+>>
+>>> I was trying to compile and run the ssl_hello_world example in the
+>>> cowboy project and am getting the following error at start-up:
+>>>
+>>>
+>>>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>>>
+>>>
+>>>        application: ssl_hello_world
+>>>
+>>>
+>>>        exited: {bad_return,
+>>>
+>>>
+>>>                 {{ssl_hello_world_app,start,[**normal,[]]},
+>>>
+>>>
+>>>                  {'EXIT',
+>>>
+>>>
+>>>                   {{badmatch,
+>>>
+>>>
+>>>                     {error,
+>>>
+>>>
+>>>                      {{shutdown,
+>>>
+>>>
+>>>                        {failed_to_start_child,ranch_**acceptors_sup,
+>>>
+>>>
+>>>                         {{case_clause,
+>>>
+>>>
+>>>                           {error,{"no such file or
+>>> directory","asn1.app"}}},
+>>>
+>>>
+>>>
+>>>   [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]},
+>>>
+>>>
+>>> I can start asn1 from the erl console so I am not sure what I am
+>>> missing. Any help is greatly appreciated.
+>>>
+>>> Best regards.
+>>>
+>>> --
+>>> -rb
+>>>
+>>>
+>>> ______________________________**_________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>>
+>>>
+>>
+>> --
+>> Lo?c Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>>
+>
+>
+>
+> --
+> -rb
+>
+
+
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131008/8752fdd7/attachment.html>
+
+From lee.sylvester at gmail.com  Wed Oct  9 15:27:25 2013
+From: lee.sylvester at gmail.com (Lee Sylvester)
+Date: Wed, 9 Oct 2013 14:27:25 +0100
+Subject: [99s-extend] Cowboy Calling Hostname
+Message-ID: <[email protected]>
+
+Hi,
+
+When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+
+Thanks,
+Lee
+
+
+
+From essen at ninenines.eu  Wed Oct  9 15:31:04 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Wed, 09 Oct 2013 15:31:04 +0200
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+cowboy_req:host/1?
+
+Please use the nice manual we have now.
+
+   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+
+On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+> Hi,
+>
+> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>
+> Thanks,
+> Lee
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From lee.sylvester at gmail.com  Wed Oct  9 17:30:21 2013
+From: lee.sylvester at gmail.com (Lee Sylvester)
+Date: Wed, 9 Oct 2013 16:30:21 +0100
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+
+Thanks,
+Lee
+
+Sent from my iPhone
+
+> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+> 
+> cowboy_req:host/1?
+> 
+> Please use the nice manual we have now.
+> 
+>  http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+> 
+>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>> Hi,
+>> 
+>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> -- 
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+From essen at ninenines.eu  Wed Oct  9 17:32:54 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 09 Oct 2013 17:32:54 +0200
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+In short: you can't.
+
+Browsers may send origin/referer/.. headers depending on the type of 
+request, but you can't rely on them to be real or even just there.
+
+On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+> Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+>
+> Thanks,
+> Lee
+>
+> Sent from my iPhone
+>
+>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>
+>> cowboy_req:host/1?
+>>
+>> Please use the nice manual we have now.
+>>
+>>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>
+>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>> Hi,
+>>>
+>>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>> --
+>> Lo?c Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From nathan at nmichaels.org  Wed Oct  9 17:51:14 2013
+From: nathan at nmichaels.org (Nathan Michaels)
+Date: Wed, 9 Oct 2013 11:51:14 -0400
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+Message-ID: <CALvUveMuMZabtizGQDURJs7x62RjZNr=NukQLF49MDtZBiPF6A@mail.gmail.com>
+
+Is the client making the request to your service on widgets.net because
+things.com sent them there, or is things.com making the request directly on
+behalf of the client? The first is what Lo?c is talking about. The second
+is the source IP of the request, which you can definitely get.
+
+
+On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> In short: you can't.
+>
+> Browsers may send origin/referer/.. headers depending on the type of
+> request, but you can't rely on them to be real or even just there.
+>
+>
+> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>
+>> Thank you.  I couldn't work out if that's the host being called from or
+>> the host name in the request.  For example, a store called things.commakes a request to my service on
+>> widgets.net.  I need to see that the request is made FROM things.com for
+>> validation purposes. Is it correct that host will provide this?
+>>
+>> Thanks,
+>> Lee
+>>
+>> Sent from my iPhone
+>>
+>>  On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>> cowboy_req:host/1?
+>>>
+>>> Please use the nice manual we have now.
+>>>
+>>>   http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_req<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req>
+>>>
+>>>  On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>> Hi,
+>>>>
+>>>> When receiving a Cowboy request, is there a way to find out which
+>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>> Bullet app, where each call can be made through a given account.  However,
+>>>> I'd like to be able to lock requests for each account to a designated
+>>>> hostname to protect that users account usage.
+>>>>
+>>>> Thanks,
+>>>> Lee
+>>>>
+>>>> ______________________________**_________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>>>
+>>>
+>>>
+>>> --
+>>> Lo?c Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>>>
+>>
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131009/cc05d6f5/attachment.html>
+
+From lee.sylvester at gmail.com  Wed Oct  9 19:28:40 2013
+From: lee.sylvester at gmail.com (Lee Sylvester)
+Date: Wed, 9 Oct 2013 18:28:40 +0100
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <CALvUveMuMZabtizGQDURJs7x62RjZNr=NukQLF49MDtZBiPF6A@mail.gmail.com>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <CALvUveMuMZabtizGQDURJs7x62RjZNr=NukQLF49MDtZBiPF6A@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Essentially, the REST service endpoint would be on widgets.net while the clients website, in this case things.com, has a JavaScript that makes an AJAX call to widgets.net.  The account on widgets.net for things.com will have the things.com domain registered to its account, so that widgets.net can check to see if the request is coming from an expected domain.
+
+Thanks,
+Lee
+
+
+On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+
+> Is the client making the request to your service on widgets.net because things.com sent them there, or is things.com making the request directly on behalf of the client? The first is what Lo?c is talking about. The second is the source IP of the request, which you can definitely get.
+> 
+> 
+> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+> In short: you can't.
+> 
+> Browsers may send origin/referer/.. headers depending on the type of request, but you can't rely on them to be real or even just there.
+> 
+> 
+> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+> Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+> 
+> Thanks,
+> Lee
+> 
+> Sent from my iPhone
+> 
+> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+> 
+> cowboy_req:host/1?
+> 
+> Please use the nice manual we have now.
+> 
+>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+> 
+> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+> Hi,
+> 
+> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+> 
+> Thanks,
+> Lee
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> 
+> 
+> -- 
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131009/7c03cefc/attachment.html>
+
+From daniel at whitehouse.id.au  Thu Oct 10 01:03:08 2013
+From: daniel at whitehouse.id.au (Daniel White)
+Date: Thu, 10 Oct 2013 10:03:08 +1100
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <CALvUveMuMZabtizGQDURJs7x62RjZNr=NukQLF49MDtZBiPF6A@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAMD5n_3RJT3Nd0p4cbgCtR1XavDXSY6kaWTbwiLwqH_bF74KOw@mail.gmail.com>
+
+Depending on your requirements, there is a high likelihood that you
+need to support pre-flight requests.  Especially if you're intending
+on providing credentials in the requests.  Many of the interesting
+headers are not simple headers (for CORS) and require a handshake
+first between browser and server to ensure the headers in question are
+allowed to be sent.
+
+This obviously limits the amount of information you can determine
+about the caller.  One alternative here, is the use of OAuth2 with the
+'access_token' query parameter.  This can be sent along with the
+pre-flight request.
+
+On the other hand, some providers (Github, IIRC) will simply validate
+a CORS request by comparing the 'Origin' against their entire list of
+registered origins.  This opens up some opportunity for abuse by other
+clients in the system, but can be further mitigated by enforcing the
+'Origin' more strictly at the authorization step of the request.
+
+As an aside, I have a cowboy middleware project to do the heavy
+lifting for CORS at https://github.com/danielwhite/cowboy_cors.
+Business policies can be implemented by means of a callback module.
+
+Cheers,
+
+
+On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+> Essentially, the REST service endpoint would be on widgets.net while the
+> clients website, in this case things.com, has a JavaScript that makes an
+> AJAX call to widgets.net.  The account on widgets.net for things.com will
+> have the things.com domain registered to its account, so that widgets.net
+> can check to see if the request is coming from an expected domain.
+>
+> Thanks,
+> Lee
+>
+>
+> On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+>
+> Is the client making the request to your service on widgets.net because
+> things.com sent them there, or is things.com making the request directly on
+> behalf of the client? The first is what Lo?c is talking about. The second is
+> the source IP of the request, which you can definitely get.
+>
+>
+> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>
+>> In short: you can't.
+>>
+>> Browsers may send origin/referer/.. headers depending on the type of
+>> request, but you can't rely on them to be real or even just there.
+>>
+>>
+>> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>>>
+>>> Thank you.  I couldn't work out if that's the host being called from or
+>>> the host name in the request.  For example, a store called things.com makes
+>>> a request to my service on widgets.net.  I need to see that the request is
+>>> made FROM things.com for validation purposes. Is it correct that host will
+>>> provide this?
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>> Sent from my iPhone
+>>>
+>>>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>>>
+>>>> cowboy_req:host/1?
+>>>>
+>>>> Please use the nice manual we have now.
+>>>>
+>>>>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>>>
+>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>>> Hi,
+>>>>>
+>>>>> When receiving a Cowboy request, is there a way to find out which
+>>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>>> Bullet app, where each call can be made through a given account.  However,
+>>>>> I'd like to be able to lock requests for each account to a designated
+>>>>> hostname to protect that users account usage.
+>>>>>
+>>>>> Thanks,
+>>>>> Lee
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>
+>>>>
+>>>>
+>>>> --
+>>>> Lo?c Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>
+>>
+>>
+>> --
+>> Lo?c Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+-- 
+Daniel White
+
+
+From lee.sylvester at gmail.com  Thu Oct 10 08:05:23 2013
+From: lee.sylvester at gmail.com (Lee Sylvester)
+Date: Thu, 10 Oct 2013 07:05:23 +0100
+Subject: [99s-extend] Cowboy Calling Hostname
+In-Reply-To: <CAMD5n_3RJT3Nd0p4cbgCtR1XavDXSY6kaWTbwiLwqH_bF74KOw@mail.gmail.com>
+References: <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <[email protected]>
+ <CALvUveMuMZabtizGQDURJs7x62RjZNr=NukQLF49MDtZBiPF6A@mail.gmail.com>
+ <[email protected]>
+ <CAMD5n_3RJT3Nd0p4cbgCtR1XavDXSY6kaWTbwiLwqH_bF74KOw@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Thank you, Daniel.  The project looks very useful.  At this stage, I don't need to strictly require calls to come from a set domain but would like this to be a hurdle for hackers.  I may set up an IP restriction instead.
+
+Thanks,
+Lee
+
+Sent from my iPhone
+
+> On Oct 10, 2013, at 12:03 AM, Daniel White <daniel at whitehouse.id.au> wrote:
+> 
+> Depending on your requirements, there is a high likelihood that you
+> need to support pre-flight requests.  Especially if you're intending
+> on providing credentials in the requests.  Many of the interesting
+> headers are not simple headers (for CORS) and require a handshake
+> first between browser and server to ensure the headers in question are
+> allowed to be sent.
+> 
+> This obviously limits the amount of information you can determine
+> about the caller.  One alternative here, is the use of OAuth2 with the
+> 'access_token' query parameter.  This can be sent along with the
+> pre-flight request.
+> 
+> On the other hand, some providers (Github, IIRC) will simply validate
+> a CORS request by comparing the 'Origin' against their entire list of
+> registered origins.  This opens up some opportunity for abuse by other
+> clients in the system, but can be further mitigated by enforcing the
+> 'Origin' more strictly at the authorization step of the request.
+> 
+> As an aside, I have a cowboy middleware project to do the heavy
+> lifting for CORS at https://github.com/danielwhite/cowboy_cors.
+> Business policies can be implemented by means of a callback module.
+> 
+> Cheers,
+> 
+> 
+>> On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>> Essentially, the REST service endpoint would be on widgets.net while the
+>> clients website, in this case things.com, has a JavaScript that makes an
+>> AJAX call to widgets.net.  The account on widgets.net for things.com will
+>> have the things.com domain registered to its account, so that widgets.net
+>> can check to see if the request is coming from an expected domain.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+>> 
+>> Is the client making the request to your service on widgets.net because
+>> things.com sent them there, or is things.com making the request directly on
+>> behalf of the client? The first is what Lo?c is talking about. The second is
+>> the source IP of the request, which you can definitely get.
+>> 
+>> 
+>>> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>> In short: you can't.
+>>> 
+>>> Browsers may send origin/referer/.. headers depending on the type of
+>>> request, but you can't rely on them to be real or even just there.
+>>> 
+>>> 
+>>>> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>>>> 
+>>>> Thank you.  I couldn't work out if that's the host being called from or
+>>>> the host name in the request.  For example, a store called things.com makes
+>>>> a request to my service on widgets.net.  I need to see that the request is
+>>>> made FROM things.com for validation purposes. Is it correct that host will
+>>>> provide this?
+>>>> 
+>>>> Thanks,
+>>>> Lee
+>>>> 
+>>>> Sent from my iPhone
+>>>> 
+>>>>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+>>>>> 
+>>>>> cowboy_req:host/1?
+>>>>> 
+>>>>> Please use the nice manual we have now.
+>>>>> 
+>>>>>  http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>>>> 
+>>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>>>> Hi,
+>>>>>> 
+>>>>>> When receiving a Cowboy request, is there a way to find out which
+>>>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>>>> Bullet app, where each call can be made through a given account.  However,
+>>>>>> I'd like to be able to lock requests for each account to a designated
+>>>>>> hostname to protect that users account usage.
+>>>>>> 
+>>>>>> Thanks,
+>>>>>> Lee
+>>>>>> 
+>>>>>> _______________________________________________
+>>>>>> Extend mailing list
+>>>>>> Extend at lists.ninenines.eu
+>>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>> 
+>>>>> 
+>>>>> 
+>>>>> --
+>>>>> Lo?c Hoguin
+>>>>> Erlang Cowboy
+>>>>> Nine Nines
+>>>>> http://ninenines.eu
+>>> 
+>>> 
+>>> 
+>>> --
+>>> Lo?c Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> 
+> -- 
+> Daniel White
+
+
+From prinbit at gmail.com  Tue Oct 15 03:53:05 2013
+From: prinbit at gmail.com (=?GB2312?B?scjB2rHIzNhQcmluYml0?=)
+Date: Tue, 15 Oct 2013 09:53:05 +0800
+Subject: [99s-extend] SSL Example
+In-Reply-To: <CAO_b8hZeQwEyDKtGbCgLWKSKDD+uW7PbeC-MZME=QVRK2xn4TA@mail.gmail.com>
+References: <CAO_b8hZeQwEyDKtGbCgLWKSKDD+uW7PbeC-MZME=QVRK2xn4TA@mail.gmail.com>
+Message-ID: <CAO_b8hbgbhKYxuh2SGA7n0SSQqCWOCjhKWzL5xhjcC4ht2h7WA@mail.gmail.com>
+
+Hi Essen,
+
+Any suggestion on the question?
+
+I can't receive any email from the lists.
+
+Thanks in advance
+
+2013/10/13 ????Prinbit <prinbit at gmail.com>:
+> Hi essen
+>
+> In your ssl example, three files are needed in ssl folder, they are
+> cowboy-ca.crt, server.crt and server.key.
+>
+> I am applying for a free ssl in startssl, and found there are only
+> server.crt and server.key generated.
+>
+> What is cowboy-ca.crt used for?
+>
+> I want to add ssl certificate in http://prinbit.com, my question is
+> that is cowboy-ca.crt is needed for me?
+>
+> Thanks in advance
+>
+> --
+> Thanks & Regards,
+>
+> PrinBit, Video Chatting and Collaborative Coding, Together
+>
+> http://prinbit.com
+
+
+
+-- 
+Thanks & Regards,
+
+PrinBit, Video Chatting and Collaborative Coding, Together
+
+http://prinbit.com
+
+
+From akonsu at gmail.com  Wed Oct 16 04:55:28 2013
+From: akonsu at gmail.com (akonsu)
+Date: Tue, 15 Oct 2013 22:55:28 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+Message-ID: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+
+Hello,
+
+the documentation for `init` at
+http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says:
+
+The receive loop will run for a duration of up to Timeout milliseconds
+after it last received data from the socket, at which point it will stop
+and send a 204 No Content reply.
+
+What socket does it refer to? I had an impression that the loop handles
+erlang messages. Do these messages come through a socket (sorry about a
+trivial question, but I am new to erlang), and this is the socket that the
+docs talk about?
+
+The reason why I am asking is because I used to have a Timeout of 60000,
+and even though messages kept coming non stop, it still kept disconnecting
+after a minute, until I set Timeout to infinity.
+
+thanks
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/94506752/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 05:01:38 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Wed, 16 Oct 2013 05:01:38 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+Message-ID: <[email protected]>
+
+The socket connected to the client.
+
+TCP isn't perfect, there is no way to be 100% sure the client is still 
+connected, hence the timeout. If the client is still up you should make 
+it reconnect.
+
+On 10/16/2013 04:55 AM, akonsu wrote:
+> Hello,
+>
+> the documentation for `init` at
+> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says:
+>
+> The receive loop will run for a duration of up to Timeout milliseconds
+> after it last received data from the socket, at which point it will stop
+> and send a 204 No Content reply.
+>
+> What socket does it refer to? I had an impression that the loop handles
+> erlang messages. Do these messages come through a socket (sorry about a
+> trivial question, but I am new to erlang), and this is the socket that
+> the docs talk about?
+>
+> The reason why I am asking is because I used to have a Timeout of 60000,
+> and even though messages kept coming non stop, it still kept
+> disconnecting after a minute, until I set Timeout to infinity.
+>
+> thanks
+> Konstantin
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Wed Oct 16 05:03:53 2013
+From: akonsu at gmail.com (akonsu)
+Date: Tue, 15 Oct 2013 23:03:53 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <[email protected]>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+
+so it will disconnect if the client only listens and sends nothing to the
+socket, correct?
+
+
+2013/10/15 Lo?c Hoguin <essen at ninenines.eu>
+
+> The socket connected to the client.
+>
+> TCP isn't perfect, there is no way to be 100% sure the client is still
+> connected, hence the timeout. If the client is still up you should make it
+> reconnect.
+>
+>
+> On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>> Hello,
+>>
+>> the documentation for `init` at
+>> http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_**loop_handler<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>says:
+>>
+>> The receive loop will run for a duration of up to Timeout milliseconds
+>> after it last received data from the socket, at which point it will stop
+>> and send a 204 No Content reply.
+>>
+>> What socket does it refer to? I had an impression that the loop handles
+>> erlang messages. Do these messages come through a socket (sorry about a
+>> trivial question, but I am new to erlang), and this is the socket that
+>> the docs talk about?
+>>
+>> The reason why I am asking is because I used to have a Timeout of 60000,
+>> and even though messages kept coming non stop, it still kept
+>> disconnecting after a minute, until I set Timeout to infinity.
+>>
+>> thanks
+>> Konstantin
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/591e8649/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 05:11:30 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 16 Oct 2013 05:11:30 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Yep. And it will also disconnect if the client sends too much. It has to 
+disconnect and reconnect eventually, there's no way around it.
+
+On 10/16/2013 05:03 AM, akonsu wrote:
+> so it will disconnect if the client only listens and sends nothing to
+> the socket, correct?
+>
+>
+> 2013/10/15 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     The socket connected to the client.
+>
+>     TCP isn't perfect, there is no way to be 100% sure the client is
+>     still connected, hence the timeout. If the client is still up you
+>     should make it reconnect.
+>
+>
+>     On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>         Hello,
+>
+>         the documentation for `init` at
+>         http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler
+>         <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>
+>         says:
+>
+>         The receive loop will run for a duration of up to Timeout
+>         milliseconds
+>         after it last received data from the socket, at which point it
+>         will stop
+>         and send a 204 No Content reply.
+>
+>         What socket does it refer to? I had an impression that the loop
+>         handles
+>         erlang messages. Do these messages come through a socket (sorry
+>         about a
+>         trivial question, but I am new to erlang), and this is the
+>         socket that
+>         the docs talk about?
+>
+>         The reason why I am asking is because I used to have a Timeout
+>         of 60000,
+>         and even though messages kept coming non stop, it still kept
+>         disconnecting after a minute, until I set Timeout to infinity.
+>
+>         thanks
+>         Konstantin
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>
+>
+>
+>
+>     --
+>     Lo?c Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Wed Oct 16 05:31:46 2013
+From: akonsu at gmail.com (akonsu)
+Date: Tue, 15 Oct 2013 23:31:46 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <[email protected]>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+
+thanks for your help. suppose that I want to stream live audio. I do not
+know how long my audio program will be, and as I stream it, if I have a
+timeout, the server will just disconnect the user that listens to the audio
+in the browser. and the browser won't reconnect. Would you suggest the
+"right" way to implement something like that? Would infinite timeout
+suffice? or is it a bad practice? another type of handler maybe?
+
+
+2013/10/15 Lo?c Hoguin <essen at ninenines.eu>
+
+> Yep. And it will also disconnect if the client sends too much. It has to
+> disconnect and reconnect eventually, there's no way around it.
+>
+>
+> On 10/16/2013 05:03 AM, akonsu wrote:
+>
+>> so it will disconnect if the client only listens and sends nothing to
+>> the socket, correct?
+>>
+>>
+>> 2013/10/15 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>>
+>>
+>>     The socket connected to the client.
+>>
+>>     TCP isn't perfect, there is no way to be 100% sure the client is
+>>     still connected, hence the timeout. If the client is still up you
+>>     should make it reconnect.
+>>
+>>
+>>     On 10/16/2013 04:55 AM, akonsu wrote:
+>>
+>>         Hello,
+>>
+>>         the documentation for `init` at
+>>         http://ninenines.eu/docs/en/__**cowboy/HEAD/manual/cowboy___**
+>> loop_handler<http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler>
+>>
+>>         <http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_**
+>> loop_handler<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>
+>> >
+>>         says:
+>>
+>>         The receive loop will run for a duration of up to Timeout
+>>         milliseconds
+>>         after it last received data from the socket, at which point it
+>>         will stop
+>>         and send a 204 No Content reply.
+>>
+>>         What socket does it refer to? I had an impression that the loop
+>>         handles
+>>         erlang messages. Do these messages come through a socket (sorry
+>>         about a
+>>         trivial question, but I am new to erlang), and this is the
+>>         socket that
+>>         the docs talk about?
+>>
+>>         The reason why I am asking is because I used to have a Timeout
+>>         of 60000,
+>>         and even though messages kept coming non stop, it still kept
+>>         disconnecting after a minute, until I set Timeout to infinity.
+>>
+>>         thanks
+>>         Konstantin
+>>
+>>
+>>         ______________________________**___________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.**ninenines.eu<Extend at lists.ninenines.eu>
+>> >
+>>         http://lists.ninenines.eu:81/_**_listinfo/extend<http://lists.ninenines.eu:81/__listinfo/extend>
+>>
+>>         <http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>> >
+>>
+>>
+>>
+>>     --
+>>     Lo?c Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>
+>>
+>>
+>
+> --
+> Lo?c Hoguin
+>
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/203060cc/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 05:40:31 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 16 Oct 2013 05:40:31 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Infinite is bad practice, yes. Infinite means some connections will 
+*never* be closed, eating FDs and memory for nothing.
+
+I'm not sure why you want to receive messages, you could just use a 
+normal handler that asks for more data, sends it, ask for more data, 
+sends it, etc.
+
+On 10/16/2013 05:31 AM, akonsu wrote:
+> thanks for your help. suppose that I want to stream live audio. I do not
+> know how long my audio program will be, and as I stream it, if I have a
+> timeout, the server will just disconnect the user that listens to the
+> audio in the browser. and the browser won't reconnect. Would you suggest
+> the "right" way to implement something like that? Would infinite timeout
+> suffice? or is it a bad practice? another type of handler maybe?
+>
+>
+> 2013/10/15 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Yep. And it will also disconnect if the client sends too much. It
+>     has to disconnect and reconnect eventually, there's no way around it.
+>
+>
+>     On 10/16/2013 05:03 AM, akonsu wrote:
+>
+>         so it will disconnect if the client only listens and sends
+>         nothing to
+>         the socket, correct?
+>
+>
+>         2013/10/15 Lo?c Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu> <mailto:essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>>>
+>
+>
+>              The socket connected to the client.
+>
+>              TCP isn't perfect, there is no way to be 100% sure the
+>         client is
+>              still connected, hence the timeout. If the client is still
+>         up you
+>              should make it reconnect.
+>
+>
+>              On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>                  Hello,
+>
+>                  the documentation for `init` at
+>         http://ninenines.eu/docs/en/____cowboy/HEAD/manual/cowboy_____loop_handler
+>         <http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler>
+>
+>
+>         <http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler
+>         <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>>
+>                  says:
+>
+>                  The receive loop will run for a duration of up to Timeout
+>                  milliseconds
+>                  after it last received data from the socket, at which
+>         point it
+>                  will stop
+>                  and send a 204 No Content reply.
+>
+>                  What socket does it refer to? I had an impression that
+>         the loop
+>                  handles
+>                  erlang messages. Do these messages come through a
+>         socket (sorry
+>                  about a
+>                  trivial question, but I am new to erlang), and this is the
+>                  socket that
+>                  the docs talk about?
+>
+>                  The reason why I am asking is because I used to have a
+>         Timeout
+>                  of 60000,
+>                  and even though messages kept coming non stop, it still
+>         kept
+>                  disconnecting after a minute, until I set Timeout to
+>         infinity.
+>
+>                  thanks
+>                  Konstantin
+>
+>
+>                  ___________________________________________________
+>                  Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.__ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         http://lists.ninenines.eu:81/____listinfo/extend
+>         <http://lists.ninenines.eu:81/__listinfo/extend>
+>
+>                  <http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>>
+>
+>
+>
+>              --
+>              Lo?c Hoguin
+>              Erlang Cowboy
+>              Nine Nines
+>         http://ninenines.eu
+>
+>
+>
+>
+>     --
+>     Lo?c Hoguin
+>
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Wed Oct 16 05:48:42 2013
+From: akonsu at gmail.com (akonsu)
+Date: Tue, 15 Oct 2013 23:48:42 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <[email protected]>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+
+1. do you mean that there is no way on the server side to tell if the
+client has disconnected?
+
+2. if I use a normal handler, I will still run into the same problem, it
+does not matter which handler I use, from the standpoint of deciding
+whether the client is still there, right?
+
+I am confused as to how I can implement my streaming and not drop the
+connection on each client and yet make sure I do close the connections when
+the clients disconnect...
+
+
+2013/10/15 Lo?c Hoguin <essen at ninenines.eu>
+
+> Infinite is bad practice, yes. Infinite means some connections will
+> *never* be closed, eating FDs and memory for nothing.
+>
+> I'm not sure why you want to receive messages, you could just use a normal
+> handler that asks for more data, sends it, ask for more data, sends it, etc.
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/bac10460/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 06:07:26 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 16 Oct 2013 06:07:26 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+Message-ID: <[email protected]>
+
+On 10/16/2013 05:48 AM, akonsu wrote:
+> 1. do you mean that there is no way on the server side to tell if the
+> client has disconnected?
+
+There are ways, and Cowboy will happily detect them. There's also the 
+problem that a side may be closed without the other side knowing about 
+it, which is why you need timeouts.
+
+> 2. if I use a normal handler, I will still run into the same problem, it
+> does not matter which handler I use, from the standpoint of deciding
+> whether the client is still there, right?
+
+If the client is gone, the send will fail. Normal handlers are pretty 
+much the same except they don't have a timeout, because your code has an 
+explicit end.
+
+> I am confused as to how I can implement my streaming and not drop the
+> connection on each client and yet make sure I do close the connections
+> when the clients disconnect...
+>
+>
+> 2013/10/15 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Infinite is bad practice, yes. Infinite means some connections will
+>     *never* be closed, eating FDs and memory for nothing.
+>
+>     I'm not sure why you want to receive messages, you could just use a
+>     normal handler that asks for more data, sends it, ask for more data,
+>     sends it, etc.
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Wed Oct 16 06:12:29 2013
+From: akonsu at gmail.com (akonsu)
+Date: Wed, 16 Oct 2013 00:12:29 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <[email protected]>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+eMAwb0ubM3O=yKmEJvrJ94Y2xVWpnPxXWO7Qx0q8kxL4+qwQ@mail.gmail.com>
+
+thanks. one more question if you do not mind. you say that we need timeouts
+when the client does not notify us when it dies. but then you say that if
+the client dies then the socket write will fail. to me this sounds like a
+contradiction. would you please clarify?
+
+(I assume that this is the problem that we are discussing:
+http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect,
+right?)
+
+
+2013/10/16 Lo?c Hoguin <essen at ninenines.eu>
+
+> On 10/16/2013 05:48 AM, akonsu wrote:
+>
+>> 1. do you mean that there is no way on the server side to tell if the
+>> client has disconnected?
+>>
+>
+> There are ways, and Cowboy will happily detect them. There's also the
+> problem that a side may be closed without the other side knowing about it,
+> which is why you need timeouts.
+>
+>
+>  2. if I use a normal handler, I will still run into the same problem, it
+>> does not matter which handler I use, from the standpoint of deciding
+>> whether the client is still there, right?
+>>
+>
+> If the client is gone, the send will fail. Normal handlers are pretty much
+> the same except they don't have a timeout, because your code has an
+> explicit end.
+>
+>  I am confused as to how I can implement my streaming and not drop the
+>> connection on each client and yet make sure I do close the connections
+>> when the clients disconnect...
+>>
+>>
+>> 2013/10/15 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>>
+>>
+>>     Infinite is bad practice, yes. Infinite means some connections will
+>>     *never* be closed, eating FDs and memory for nothing.
+>>
+>>     I'm not sure why you want to receive messages, you could just use a
+>>     normal handler that asks for more data, sends it, ask for more data,
+>>     sends it, etc.
+>>
+>>
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131016/edbc349c/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 06:35:43 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 16 Oct 2013 06:35:43 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwb0ubM3O=yKmEJvrJ94Y2xVWpnPxXWO7Qx0q8kxL4+qwQ@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwb0ubM3O=yKmEJvrJ94Y2xVWpnPxXWO7Qx0q8kxL4+qwQ@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Loop handlers are designed to wait for a long time with the socket 
+*idle* and then eventually send one response then close the socket. 
+Things like long-polling.
+
+What you are doing is just streaming, for which you do not need a 
+timeout because the socket isn't idle. You are just sending a large 
+response, and normal handlers are perfectly capable of doing that.
+
+On 10/16/2013 06:12 AM, akonsu wrote:
+> thanks. one more question if you do not mind. you say that we need
+> timeouts when the client does not notify us when it dies. but then you
+> say that if the client dies then the socket write will fail. to me this
+> sounds like a contradiction. would you please clarify?
+>
+> (I assume that this is the problem that we are discussing:
+> http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect,
+> right?)
+>
+>
+> 2013/10/16 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     On 10/16/2013 05:48 AM, akonsu wrote:
+>
+>         1. do you mean that there is no way on the server side to tell
+>         if the
+>         client has disconnected?
+>
+>
+>     There are ways, and Cowboy will happily detect them. There's also
+>     the problem that a side may be closed without the other side knowing
+>     about it, which is why you need timeouts.
+>
+>
+>         2. if I use a normal handler, I will still run into the same
+>         problem, it
+>         does not matter which handler I use, from the standpoint of deciding
+>         whether the client is still there, right?
+>
+>
+>     If the client is gone, the send will fail. Normal handlers are
+>     pretty much the same except they don't have a timeout, because your
+>     code has an explicit end.
+>
+>         I am confused as to how I can implement my streaming and not
+>         drop the
+>         connection on each client and yet make sure I do close the
+>         connections
+>         when the clients disconnect...
+>
+>
+>         2013/10/15 Lo?c Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu> <mailto:essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>>>
+>
+>
+>              Infinite is bad practice, yes. Infinite means some
+>         connections will
+>              *never* be closed, eating FDs and memory for nothing.
+>
+>              I'm not sure why you want to receive messages, you could
+>         just use a
+>              normal handler that asks for more data, sends it, ask for
+>         more data,
+>              sends it, etc.
+>
+>
+>
+>     --
+>     Lo?c Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Wed Oct 16 06:42:02 2013
+From: akonsu at gmail.com (akonsu)
+Date: Wed, 16 Oct 2013 00:42:02 -0400
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <[email protected]>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwb0ubM3O=yKmEJvrJ94Y2xVWpnPxXWO7Qx0q8kxL4+qwQ@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CA+eMAwbh8xH9Etiev66oA90p7aw3RjffnYoBd8b3Kuab0Bg6WQ@mail.gmail.com>
+
+ok. the data that I need to send are coming as erlang messages to the
+process that runs my handler. so it sounds like if I want to use the
+"normal" cowboy_http_handler, then I need a receive loop inside handle(Req,
+State) callback, right? Basically, my response stream will potentially
+never end, I do not know how to handle this properly in cowboy...
+
+
+2013/10/16 Lo?c Hoguin <essen at ninenines.eu>
+
+> Loop handlers are designed to wait for a long time with the socket *idle*
+> and then eventually send one response then close the socket. Things like
+> long-polling.
+>
+> What you are doing is just streaming, for which you do not need a timeout
+> because the socket isn't idle. You are just sending a large response, and
+> normal handlers are perfectly capable of doing that.
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131016/abe38a1a/attachment.html>
+
+From essen at ninenines.eu  Wed Oct 16 06:48:05 2013
+From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=)
+Date: Wed, 16 Oct 2013 06:48:05 +0200
+Subject: [99s-extend] timeout in cowboy loop handler
+In-Reply-To: <CA+eMAwbh8xH9Etiev66oA90p7aw3RjffnYoBd8b3Kuab0Bg6WQ@mail.gmail.com>
+References: <CA+eMAwZDCwOi32RY_mwKY7w-O1Q+PTGQwp4vY72KJY3C-Q8_Xw@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwYP_rRrgTSqwv7nD2UAJkvKDzpKDfkrfLaLJTff_Dg7ig@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwY75j1G2Ew13WY5dMCT8_E41b85OjoKdFHw9AZfX9qQcg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwZW64xGtVxca35PngCXBJEh8oaQk9TuOPesXf48XUH=qg@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwb0ubM3O=yKmEJvrJ94Y2xVWpnPxXWO7Qx0q8kxL4+qwQ@mail.gmail.com>
+ <[email protected]>
+ <CA+eMAwbh8xH9Etiev66oA90p7aw3RjffnYoBd8b3Kuab0Bg6WQ@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Then use a loop handler, set its timeout to infinity *but* create a new 
+timeout that checks regularly if the handler is active or not to be able 
+to kill it off in case something happens.
+
+On 10/16/2013 06:42 AM, akonsu wrote:
+> ok. the data that I need to send are coming as erlang messages to the
+> process that runs my handler. so it sounds like if I want to use the
+> "normal" cowboy_http_handler, then I need a receive loop
+> inside handle(Req, State) callback, right? Basically, my response stream
+> will potentially never end, I do not know how to handle this properly in
+> cowboy...
+>
+>
+> 2013/10/16 Lo?c Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Loop handlers are designed to wait for a long time with the socket
+>     *idle* and then eventually send one response then close the socket.
+>     Things like long-polling.
+>
+>     What you are doing is just streaming, for which you do not need a
+>     timeout because the socket isn't idle. You are just sending a large
+>     response, and normal handlers are perfectly capable of doing that.
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From akonsu at gmail.com  Fri Oct 18 15:15:37 2013
+From: akonsu at gmail.com (akonsu)
+Date: Fri, 18 Oct 2013 09:15:37 -0400
+Subject: [99s-extend] handler and a linked process
+Message-ID: <CA+eMAwZE0WqFNH0=usVp0ykdGhNE0y7QoaDoRRNcMMveucy7Qw@mail.gmail.com>
+
+Hi,
+
+I have a handler that spawns a process and links to this process. the new
+process does not trap exit signals.
+
+When I open the URL that is handled by this handler in the browser, and
+stop the browser before the handler finishes the request, the handler is
+terminated and my terminate function is called with the Reason set to
+{error,closed} or something similar.
+
+When this happens, the linked process does not get killed, so I have to
+call exit on it from the terminate function.
+
+is this by design? I suppose when I cancel the browser request, the handler
+is exited with normal exit code, correct? could you point me to the source
+code for that part? it is perhaps in the "ranch" repo, no?
+
+thanks in advance
+
+konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131018/00d4df12/attachment.html>
+
+From essen at ninenines.eu  Mon Oct 21 15:07:34 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Mon, 21 Oct 2013 15:07:34 +0200
+Subject: [99s-extend] handler and a linked process
+In-Reply-To: <CA+eMAwZE0WqFNH0=usVp0ykdGhNE0y7QoaDoRRNcMMveucy7Qw@mail.gmail.com>
+References: <CA+eMAwZE0WqFNH0=usVp0ykdGhNE0y7QoaDoRRNcMMveucy7Qw@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Hey,
+
+I'm guessing you use loop handler or websocket handler? The browser 
+closing the connection in these cases is perfectly normal, that's part 
+of the deal. What you can do is monitor the connection process from the 
+other process if you need to go down in all cases. Links are only useful 
+for crashing on errors.
+
+On 10/18/2013 03:15 PM, akonsu wrote:
+> Hi,
+>
+> I have a handler that spawns a process and links to this process. the
+> new process does not trap exit signals.
+>
+> When I open the URL that is handled by this handler in the browser, and
+> stop the browser before the handler finishes the request, the handler is
+> terminated and my terminate function is called with the Reason set to
+> {error,closed} or something similar.
+>
+> When this happens, the linked process does not get killed, so I have to
+> call exit on it from the terminate function.
+>
+> is this by design? I suppose when I cancel the browser request, the
+> handler is exited with normal exit code, correct? could you point me to
+> the source code for that part? it is perhaps in the "ranch" repo, no?
+>
+> thanks in advance
+>
+> konstantin
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From antonio.valente at statpro.com  Tue Oct 22 10:51:14 2013
+From: antonio.valente at statpro.com (Antonio Valente)
+Date: Tue, 22 Oct 2013 10:51:14 +0200
+Subject: [99s-extend] Generate url in cowboy
+Message-ID: <[email protected]>
+
+Hi all,
+I need to automatically generate urls from the dispatcher configuration: 
+I'm looking for some kind of function that, given the dispatcher 
+configuration, a module and a list of bindings, returns an url.
+
+For example, if I have the following dispatch configuration:
+
+     [
+     {'_', [
+
+     {"/api/v1/container/:resource/something", a_module, []},
+     ]}
+     ].
+
+I'd like to do something like:
+
+<<"/api/v1/container/replaced/something">> = generate_url(Dispatch, 
+a_module, [{resource, "replaced"}]).
+
+Is there such a function? If not, can you give me some advice to write one?
+
+Thanks
+Antonio
+
+
+This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Any views or opinions presented in this email are solely those of the author and might not represent those of StatPro. Warning: Although StatPro has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
+
+
+From Rolph.deRuiter at spilgames.com  Tue Oct 29 10:00:53 2013
+From: Rolph.deRuiter at spilgames.com (Rolph de Ruiter)
+Date: Tue, 29 Oct 2013 09:00:53 +0000
+Subject: [99s-extend] cowboy_rest, POST and redirect
+Message-ID: <CE9537D4.769B%[email protected]>
+
+Hi,
+
+I'm using cowboy_rest for a part of our api to handle POST requests. Under certain conditions, I would like to redirect to a new location (based on availability of the redirect qs parameter).
+I was unable to get the moved_temporarily/2 callback to work (was not invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. This works, however, every time it produces an error in the emulator process:
+ [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26 bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7 bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+
+Can you point me out how to (ideally) make use of moved_temporarily/2 or how I can prevent cowboy_rest from wanting to reply with 204 in this case?
+
+Cheers,
+Rolph
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/5fc5da75/attachment.html>
+
+From essen at ninenines.eu  Tue Oct 29 10:09:20 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 29 Oct 2013 10:09:20 +0100
+Subject: [99s-extend] cowboy_rest, POST and redirect
+In-Reply-To: <CE9537D4.769B%[email protected]>
+References: <CE9537D4.769B%[email protected]>
+Message-ID: <[email protected]>
+
+On 10/29/2013 10:00 AM, Rolph de Ruiter wrote:
+> Hi,
+>
+> I'm using cowboy_rest for a part of our api to handle POST requests.
+> Under certain conditions, I would like to redirect to a new location
+> (based on availability of the redirect qs parameter).
+> I was unable to get the moved_temporarily/2 callback to work (was not
+> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4.
+> This works, however, every time it produces an error in the emulator
+> process:
+>   [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with
+> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0
+> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4
+> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26
+> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5
+> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14
+> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27
+> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7
+> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14
+> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6
+> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21
+> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+>
+> Can you point me out how to (ideally) make use of moved_temporarily/2 or
+> how I can prevent cowboy_rest from wanting to reply with 204 in this case?
+
+moved_temporarily is only called if the resource previously existed.
+
+As for calling reply yourself, you just need to return {halt, NewReq, 
+State} afterwards.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From Rolph.deRuiter at spilgames.com  Tue Oct 29 10:16:15 2013
+From: Rolph.deRuiter at spilgames.com (Rolph de Ruiter)
+Date: Tue, 29 Oct 2013 09:16:15 +0000
+Subject: [99s-extend] cowboy_rest, POST and redirect
+In-Reply-To: <CE953AD7.76AD%[email protected]>
+Message-ID: <CE953B4E.76B1%[email protected]>
+
+(forgot to include the list)
+
+On 10/29/13 10:14 AM, "Rolph de Ruiter" <Rolph.deRuiter at spilgames.com>
+wrote:
+
+>Thanks!
+>
+>{halt, NewReq, State} worked like a charm :)
+>
+>Cheers,
+>Rolph
+>
+>On 10/29/13 10:09 AM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+>
+>>On 10/29/2013 10:00 AM, Rolph de Ruiter wrote:
+>>> Hi,
+>>>
+>>> I'm using cowboy_rest for a part of our api to handle POST requests.
+>>> Under certain conditions, I would like to redirect to a new location
+>>> (based on availability of the redirect qs parameter).
+>>> I was unable to get the moved_temporarily/2 callback to work (was not
+>>> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4.
+>>> This works, however, every time it produces an error in the emulator
+>>> process:
+>>>   [error] emulator Error in process <0.509.0> on node 'api at dev.loc'
+>>>with
+>>> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0
+>>> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4
+>>> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15
+>>>bytes>>,undefined,8000,<<26
+>>> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5
+>>> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14
+>>> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27
+>>> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7
+>>> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14
+>>> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6
+>>> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21
+>>> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+>>>
+>>> Can you point me out how to (ideally) make use of moved_temporarily/2
+>>>or
+>>> how I can prevent cowboy_rest from wanting to reply with 204 in this
+>>>case?
+>>
+>>moved_temporarily is only called if the resource previously existed.
+>>
+>>As for calling reply yourself, you just need to return {halt, NewReq,
+>>State} afterwards.
+>>
+>>-- 
+>>Lo?c Hoguin
+>>Erlang Cowboy
+>>Nine Nines
+>>http://ninenines.eu
+>
+
+
+
+From daniel.goertzen at gmail.com  Tue Oct 29 21:25:54 2013
+From: daniel.goertzen at gmail.com (Daniel Goertzen)
+Date: Tue, 29 Oct 2013 15:25:54 -0500
+Subject: [99s-extend] REST handler failure
+Message-ID: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+
+My situation is that I have a rest handler that may fail due to invalid url
+segments.  Example situation:
+
+
+init(_Transport, _Req, _Opts) ->
+        {upgrade, protocol, cowboy_rest}.
+
+content_types_provided(Req, State) ->
+    {[{<<"application/json">>, get_json}], Req, State}.
+
+get_json(Req0, State) ->
+    {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+[param1, param2, param3, ....]),
+
+    case catch other_module:request(Params) of
+        {'EXIT', {badarg, _}} ->
+            hmmm, Params were bad and I would like to return a 404 code now.
+        Result ->
+            {jiffy:encode(Result), Req1, State}
+    end.
+
+
+
+So I would like to return a 404 code when my underlying request function
+fails, but it appears my choices are:
+
+- return a 200 (ok) response with data.
+- crash and cause a 500 (Internal Server Error) response to be returned.
+Not exactly the sentiment I want.
+
+
+Is there some other way to cause a 404 response?
+
+I realize I could add path constraint functions, but I will be replicating
+logic from my underlying request function.  Furthermore, the constraint
+functions consider parameters in isolation, so that won't work if the
+validity of parameters is coupled.
+
+Thanks,
+Dan.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/a9204600/attachment.html>
+
+From ivan at llaisdy.com  Tue Oct 29 22:01:30 2013
+From: ivan at llaisdy.com (Ivan uemlianin)
+Date: Tue, 29 Oct 2013 22:01:30 +0100
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+
+Ivan
+
+--
+festina lente
+
+
+On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+
+> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+> 
+> 
+> init(_Transport, _Req, _Opts) ->
+>         {upgrade, protocol, cowboy_rest}.
+> 
+> content_types_provided(Req, State) ->
+>     {[{<<"application/json">>, get_json}], Req, State}.
+> 
+> get_json(Req0, State) ->
+>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+> 
+>     case catch other_module:request(Params) of
+>         {'EXIT', {badarg, _}} ->
+>             hmmm, Params were bad and I would like to return a 404 code now.
+>         Result ->
+>             {jiffy:encode(Result), Req1, State}
+>     end.
+> 
+> 
+> 
+> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+> 
+> - return a 200 (ok) response with data.
+> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+> 
+> 
+> Is there some other way to cause a 404 response?
+> 
+> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+> 
+> Thanks,
+> Dan.
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/3df30c1d/attachment.html>
+
+From daniel.goertzen at gmail.com  Wed Oct 30 15:58:41 2013
+From: daniel.goertzen at gmail.com (Daniel Goertzen)
+Date: Wed, 30 Oct 2013 09:58:41 -0500
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <[email protected]>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+
+Well, this sort of works.  I tried this in the response handler:
+
+            {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+that gets used">>, Req1),
+            {<<"this body gets ignored">>, Req2, State};
+
+
+
+The client receives a 404 response, but cowboy crashes:
+
+=ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+Error in process <0.131.0> with exit value:
+{function_clause,[{cowboy_req,reply,[200,[],<<31
+bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+
+
+
+The issue is that the REST wrapper wants to do the cowboy_req:reply(), and
+when we do the call we cause the wrapper's call to fail.
+
+Dan.
+
+
+
+On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+
+> Sorry for terse but I only have a phone. Why can't you return a 404 here?
+>  Using something like cowboy:reply(404, ...
+>
+> Ivan
+>
+> --
+> festina lente
+>
+>
+> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+>
+> My situation is that I have a rest handler that may fail due to invalid
+> url segments.  Example situation:
+>
+>
+> init(_Transport, _Req, _Opts) ->
+>         {upgrade, protocol, cowboy_rest}.
+>
+> content_types_provided(Req, State) ->
+>     {[{<<"application/json">>, get_json}], Req, State}.
+>
+> get_json(Req0, State) ->
+>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+> [param1, param2, param3, ....]),
+>
+>     case catch other_module:request(Params) of
+>         {'EXIT', {badarg, _}} ->
+>             hmmm, Params were bad and I would like to return a 404 code
+> now.
+>         Result ->
+>             {jiffy:encode(Result), Req1, State}
+>     end.
+>
+>
+>
+> So I would like to return a 404 code when my underlying request function
+> fails, but it appears my choices are:
+>
+> - return a 200 (ok) response with data.
+> - crash and cause a 500 (Internal Server Error) response to be returned.
+> Not exactly the sentiment I want.
+>
+>
+> Is there some other way to cause a 404 response?
+>
+> I realize I could add path constraint functions, but I will be replicating
+> logic from my underlying request function.  Furthermore, the constraint
+> functions consider parameters in isolation, so that won't work if the
+> validity of parameters is coupled.
+>
+> Thanks,
+> Dan.
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/460453c8/attachment.html>
+
+From tilman.holschuh at gmail.com  Wed Oct 30 16:25:02 2013
+From: tilman.holschuh at gmail.com (Tilman Holschuh)
+Date: Wed, 30 Oct 2013 08:25:02 -0700
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+ <[email protected]>
+ <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Why not let resource_exists/2 return false when your resource does not exist? You will get 404 on false. This way you separate the implementation for turning your data to json from checking if the request went to the correct resource. 
+
+- Tilman
+
+On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote:
+
+> Well, this sort of works.  I tried this in the response handler:
+> 
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+> 
+> 
+> 
+> The client receives a 404 response, but cowboy crashes:
+> 
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... 
+> 
+> 
+> 
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail.
+> 
+> Dan.
+> 
+> 
+> 
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+> Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+> 
+> Ivan
+> 
+> --
+> festina lente
+> 
+> 
+> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+> 
+>> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+>> 
+>> 
+>> init(_Transport, _Req, _Opts) ->
+>>         {upgrade, protocol, cowboy_rest}.
+>> 
+>> content_types_provided(Req, State) ->
+>>     {[{<<"application/json">>, get_json}], Req, State}.
+>> 
+>> get_json(Req0, State) ->
+>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+>> 
+>>     case catch other_module:request(Params) of
+>>         {'EXIT', {badarg, _}} ->
+>>             hmmm, Params were bad and I would like to return a 404 code now.
+>>         Result ->
+>>             {jiffy:encode(Result), Req1, State}
+>>     end.
+>> 
+>> 
+>> 
+>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+>> 
+>> - return a 200 (ok) response with data.
+>> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+>> 
+>> 
+>> Is there some other way to cause a 404 response?
+>> 
+>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+>> 
+>> Thanks,
+>> Dan.
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+From ivan at llaisdy.com  Wed Oct 30 16:27:15 2013
+From: ivan at llaisdy.com (Ivan uemlianin)
+Date: Wed, 30 Oct 2013 16:27:15 +0100
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+ <[email protected]>
+ <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+Message-ID: <[email protected]>
+
+Instead of <<"this body ignored">> can you return the atom halt?
+
+#dontevenhaveanyofmycodewithme:(
+
+Ivan
+
+--
+festina lente
+
+
+On 30 Oct 2013, at 15:58, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+
+> Well, this sort of works.  I tried this in the response handler:
+> 
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+> 
+> 
+> 
+> The client receives a 404 response, but cowboy crashes:
+> 
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... 
+> 
+> 
+> 
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail.
+> 
+> Dan.
+> 
+> 
+> 
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+>> Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+>> 
+>> Ivan
+>> 
+>> --
+>> festina lente
+>> 
+>> 
+>> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+>> 
+>>> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+>>> 
+>>> 
+>>> init(_Transport, _Req, _Opts) ->
+>>>         {upgrade, protocol, cowboy_rest}.
+>>> 
+>>> content_types_provided(Req, State) ->
+>>>     {[{<<"application/json">>, get_json}], Req, State}.
+>>> 
+>>> get_json(Req0, State) ->
+>>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+>>> 
+>>>     case catch other_module:request(Params) of
+>>>         {'EXIT', {badarg, _}} ->
+>>>             hmmm, Params were bad and I would like to return a 404 code now.
+>>>         Result ->
+>>>             {jiffy:encode(Result), Req1, State}
+>>>     end.
+>>> 
+>>> 
+>>> 
+>>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+>>> 
+>>> - return a 200 (ok) response with data.
+>>> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+>>> 
+>>> 
+>>> Is there some other way to cause a 404 response?
+>>> 
+>>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+>>> 
+>>> Thanks,
+>>> Dan.
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/6e8ec2f0/attachment.html>
+
+From daniel.goertzen at gmail.com  Wed Oct 30 16:32:47 2013
+From: daniel.goertzen at gmail.com (Daniel Goertzen)
+Date: Wed, 30 Oct 2013 10:32:47 -0500
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <[email protected]>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+ <[email protected]>
+ <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAJCf5Rx_o66FDE-91kX_=KBQou9wcx+UEenGPFYLE2nR_PRh8g@mail.gmail.com>
+
+Returning 'halt' caused a status code of 204.
+
+Dan.
+
+
+On Wed, Oct 30, 2013 at 10:27 AM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+
+> Instead of <<"this body ignored">> can you return the atom halt?
+>
+> #dontevenhaveanyofmycodewithme:(
+>
+> Ivan
+>
+> --
+> festina lente
+>
+>
+> On 30 Oct 2013, at 15:58, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+>
+> Well, this sort of works.  I tried this in the response handler:
+>
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+> that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+>
+>
+>
+> The client receives a 404 response, but cowboy crashes:
+>
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value:
+> {function_clause,[{cowboy_req,reply,[200,[],<<31
+> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+>
+>
+>
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and
+> when we do the call we cause the wrapper's call to fail.
+>
+> Dan.
+>
+>
+>
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+>
+>> Sorry for terse but I only have a phone. Why can't you return a 404 here?
+>>  Using something like cowboy:reply(404, ...
+>>
+>> Ivan
+>>
+>> --
+>> festina lente
+>>
+>>
+>> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+>> wrote:
+>>
+>> My situation is that I have a rest handler that may fail due to invalid
+>> url segments.  Example situation:
+>>
+>>
+>> init(_Transport, _Req, _Opts) ->
+>>         {upgrade, protocol, cowboy_rest}.
+>>
+>> content_types_provided(Req, State) ->
+>>     {[{<<"application/json">>, get_json}], Req, State}.
+>>
+>> get_json(Req0, State) ->
+>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+>> [param1, param2, param3, ....]),
+>>
+>>     case catch other_module:request(Params) of
+>>         {'EXIT', {badarg, _}} ->
+>>             hmmm, Params were bad and I would like to return a 404 code
+>> now.
+>>         Result ->
+>>             {jiffy:encode(Result), Req1, State}
+>>     end.
+>>
+>>
+>>
+>> So I would like to return a 404 code when my underlying request function
+>> fails, but it appears my choices are:
+>>
+>> - return a 200 (ok) response with data.
+>> - crash and cause a 500 (Internal Server Error) response to be returned.
+>> Not exactly the sentiment I want.
+>>
+>>
+>> Is there some other way to cause a 404 response?
+>>
+>> I realize I could add path constraint functions, but I will be
+>> replicating logic from my underlying request function.  Furthermore, the
+>> constraint functions consider parameters in isolation, so that won't work
+>> if the validity of parameters is coupled.
+>>
+>> Thanks,
+>> Dan.
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/0ab7c8ee/attachment.html>
+
+From daniel.goertzen at gmail.com  Wed Oct 30 16:46:37 2013
+From: daniel.goertzen at gmail.com (Daniel Goertzen)
+Date: Wed, 30 Oct 2013 10:46:37 -0500
+Subject: [99s-extend] REST handler failure
+In-Reply-To: <[email protected]>
+References: <CAJCf5Rz0mKmouz5DEunOOZ+b21bfLCjyQy7ssbHAgUp+3rGCaw@mail.gmail.com>
+ <[email protected]>
+ <CAJCf5RzwUz1moQooTpMp33tFn8R9xkhxqOnR0joBSUSTwJ_CoQ@mail.gmail.com>
+ <[email protected]>
+Message-ID: <CAJCf5RzwO4nNcv=2Ezf7aMQqFShPhLs4zaYoBBunmzuC7Wp4uQ@mail.gmail.com>
+
+That's what I was looking for, thanks!
+
+Dan.
+
+
+On Wed, Oct 30, 2013 at 10:25 AM, Tilman Holschuh <tilman.holschuh at gmail.com
+> wrote:
+
+> Why not let resource_exists/2 return false when your resource does not
+> exist? You will get 404 on false. This way you separate the implementation
+> for turning your data to json from checking if the request went to the
+> correct resource.
+>
+> - Tilman
+>
+> On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote:
+>
+> > Well, this sort of works.  I tried this in the response handler:
+> >
+> >             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+> that gets used">>, Req1),
+> >             {<<"this body gets ignored">>, Req2, State};
+> >
+> >
+> >
+> > The client receives a 404 response, but cowboy crashes:
+> >
+> > =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> > Error in process <0.131.0> with exit value:
+> {function_clause,[{cowboy_req,reply,[200,[],<<31
+> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+> >
+> >
+> >
+> > The issue is that the REST wrapper wants to do the cowboy_req:reply(),
+> and when we do the call we cause the wrapper's call to fail.
+> >
+> > Dan.
+> >
+> >
+> >
+> > On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com>
+> wrote:
+> > Sorry for terse but I only have a phone. Why can't you return a 404
+> here?  Using something like cowboy:reply(404, ...
+> >
+> > Ivan
+> >
+> > --
+> > festina lente
+> >
+> >
+> > On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+> >
+> >> My situation is that I have a rest handler that may fail due to invalid
+> url segments.  Example situation:
+> >>
+> >>
+> >> init(_Transport, _Req, _Opts) ->
+> >>         {upgrade, protocol, cowboy_rest}.
+> >>
+> >> content_types_provided(Req, State) ->
+> >>     {[{<<"application/json">>, get_json}], Req, State}.
+> >>
+> >> get_json(Req0, State) ->
+> >>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+> [param1, param2, param3, ....]),
+> >>
+> >>     case catch other_module:request(Params) of
+> >>         {'EXIT', {badarg, _}} ->
+> >>             hmmm, Params were bad and I would like to return a 404 code
+> now.
+> >>         Result ->
+> >>             {jiffy:encode(Result), Req1, State}
+> >>     end.
+> >>
+> >>
+> >>
+> >> So I would like to return a 404 code when my underlying request
+> function fails, but it appears my choices are:
+> >>
+> >> - return a 200 (ok) response with data.
+> >> - crash and cause a 500 (Internal Server Error) response to be
+> returned.  Not exactly the sentiment I want.
+> >>
+> >>
+> >> Is there some other way to cause a 404 response?
+> >>
+> >> I realize I could add path constraint functions, but I will be
+> replicating logic from my underlying request function.  Furthermore, the
+> constraint functions consider parameters in isolation, so that won't work
+> if the validity of parameters is coupled.
+> >>
+> >> Thanks,
+> >> Dan.
+> >> _______________________________________________
+> >> Extend mailing list
+> >> Extend at lists.ninenines.eu
+> >> http://lists.ninenines.eu:81/listinfo/extend
+> >
+> > _______________________________________________
+> > Extend mailing list
+> > Extend at lists.ninenines.eu
+> > http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/3ea4ac64/attachment.html>
+