Add old mailing list archives

1 files changed, 948 insertions, 0 deletions

diff --git a/archives/extend/2013-February.txt b/archives/extend/2013-February.txt
new file mode 100644
index 00000000..7a325ec7
--- /dev/null
+++ b/archives/extend/2013-February.txt
@@ -0,0 +1,948 @@
+From jeremy at quarkgames.com  Mon Feb  4 21:10:21 2013
+From: jeremy at quarkgames.com (Jeremy Ong)
+Date: Mon, 4 Feb 2013 12:10:21 -0800
+Subject: [99s-extend] Cowboy Makefile
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <CAKD1GY7+fvMOR6PhOz=QGAi8r2T_Obf4gCjaH4hN_=J+hNyw4w@mail.gmail.com>
+
+It is rebar compatible
+
+https://github.com/extend/cowboy/blob/master/rebar.config
+
+I use it with rebar all the time.
+
+
+On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com> wrote:
+
+> Hi,
+> I understand the move away from Rebar but I'd like to see the project to
+> be still Rebar-compatible. Would that be a problem? Mainly I am thinking
+> about dependencies. The Cowboy Makefile assumes that Ranch is in its deps
+> folder. If Cowboy is a part of a bigger application, and most often it will
+> be in such a role rather than a standalone application, then all
+> dependencies should be kept in one place. In that case it would be the main
+> project's deps folder, not Cowboy's deps folder. Can the compilation
+> process be split into compiling Cowboy dependencies separately from Cowboy
+> itself?
+>
+> something like:
+>
+> all: compile-deps compile-cowboy
+>
+> Then if Cowboy is a dependency itself it may be just compiled without the
+> dependency (as it will be compiled when the main project is compiled).
+>
+> ______________________________**_________________
+> 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/20130204/3c258140/attachment.html>
+
+From list1 at gjunka.com  Mon Feb  4 22:50:14 2013
+From: list1 at gjunka.com (Grzegorz Junka)
+Date: Mon, 04 Feb 2013 21:50:14 +0000
+Subject: [99s-extend] Cowboy Makefile
+In-Reply-To: <CAKD1GY7+fvMOR6PhOz=QGAi8r2T_Obf4gCjaH4hN_=J+hNyw4w@mail.gmail.com>
+References: <[email protected]>
+ <CAKD1GY7+fvMOR6PhOz=QGAi8r2T_Obf4gCjaH4hN_=J+hNyw4w@mail.gmail.com>
+Message-ID: <[email protected]>
+
+deps/ranch:
+@mkdir -p $(DEPS_DIR)
+git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch
+cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN)
+
+
+Am I to understand that the only way of having the dependencies in 
+another folder than cowboy/deps is to use Rebar (e.g. if compiling using 
+the makefile it will always assume that dependencies are in local deps 
+folder)?
+
+Would be good to have a target to compile cowboy without dependencies.
+
+
+On 04/02/2013 20:10, Jeremy Ong wrote:
+> It is rebar compatible
+>
+> https://github.com/extend/cowboy/blob/master/rebar.config
+>
+> I use it with rebar all the time.
+>
+>
+> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com 
+> <mailto:list1 at gjunka.com>> wrote:
+>
+>     Hi,
+>     I understand the move away from Rebar but I'd like to see the
+>     project to be still Rebar-compatible. Would that be a problem?
+>     Mainly I am thinking about dependencies. The Cowboy Makefile
+>     assumes that Ranch is in its deps folder. If Cowboy is a part of a
+>     bigger application, and most often it will be in such a role
+>     rather than a standalone application, then all dependencies should
+>     be kept in one place. In that case it would be the main project's
+>     deps folder, not Cowboy's deps folder. Can the compilation process
+>     be split into compiling Cowboy dependencies separately from Cowboy
+>     itself?
+>
+>     something like:
+>
+>     all: compile-deps compile-cowboy
+>
+>     Then if Cowboy is a dependency itself it may be just compiled
+>     without the dependency (as it will be compiled when the main
+>     project is compiled).
+>
+>     _______________________________________________
+>     Extend mailing list
+>     Extend at lists.ninenines.eu <mailto: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/20130204/c34e6aa6/attachment.html>
+
+From essen at ninenines.eu  Mon Feb  4 22:58:39 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Mon, 04 Feb 2013 22:58:39 +0100
+Subject: [99s-extend] Cowboy Makefile
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <CAKD1GY7+fvMOR6PhOz=QGAi8r2T_Obf4gCjaH4hN_=J+hNyw4w@mail.gmail.com>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+Cowboy is still compatible with rebar like before, there's no change you 
+need to do.
+
+If however you would like to compile using the Makefile regardless, 
+there's a small thing that needs to be fixed before it's good.
+
+On 02/04/2013 10:50 PM, Grzegorz Junka wrote:
+> deps/ranch:
+> @mkdir -p $(DEPS_DIR)
+> git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch
+> cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN)
+>
+>
+> Am I to understand that the only way of having the dependencies in
+> another folder than cowboy/deps is to use Rebar (e.g. if compiling using
+> the makefile it will always assume that dependencies are in local deps
+> folder)?
+>
+> Would be good to have a target to compile cowboy without dependencies.
+>
+>
+> On 04/02/2013 20:10, Jeremy Ong wrote:
+>> It is rebar compatible
+>>
+>> https://github.com/extend/cowboy/blob/master/rebar.config
+>>
+>> I use it with rebar all the time.
+>>
+>>
+>> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com
+>> <mailto:list1 at gjunka.com>> wrote:
+>>
+>>     Hi,
+>>     I understand the move away from Rebar but I'd like to see the
+>>     project to be still Rebar-compatible. Would that be a problem?
+>>     Mainly I am thinking about dependencies. The Cowboy Makefile
+>>     assumes that Ranch is in its deps folder. If Cowboy is a part of a
+>>     bigger application, and most often it will be in such a role
+>>     rather than a standalone application, then all dependencies should
+>>     be kept in one place. In that case it would be the main project's
+>>     deps folder, not Cowboy's deps folder. Can the compilation process
+>>     be split into compiling Cowboy dependencies separately from Cowboy
+>>     itself?
+>>
+>>     something like:
+>>
+>>     all: compile-deps compile-cowboy
+>>
+>>     Then if Cowboy is a dependency itself it may be just compiled
+>>     without the dependency (as it will be compiled when the main
+>>     project is compiled).
+>>
+>>     _______________________________________________
+>>     Extend mailing list
+>>     Extend at lists.ninenines.eu <mailto: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
+>
+
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From elinsn at gmail.com  Thu Feb  7 11:04:05 2013
+From: elinsn at gmail.com (Sergey Yelin)
+Date: Thu, 7 Feb 2013 14:04:05 +0400
+Subject: [99s-extend] Big body via REST
+Message-ID: <[email protected]>
+
+Hi list,
+
+how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+
+Thanks in advance.
+
+---
+Best regards,
+Sergey Yelin.
+
+From essen at ninenines.eu  Thu Feb  7 15:41:03 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Thu, 07 Feb 2013 15:41:03 +0100
+Subject: [99s-extend] Big body via REST
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+On 02/07/2013 11:04 AM, Sergey Yelin wrote:
+> Hi list,
+>
+> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+
+Hey,
+
+If you know the size, reply with {stream, Size, StreamFun}, otherwise 
+{stream, StreamFun}, with StreamFun the function that will send all the 
+data to the socket.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From elinsn at gmail.com  Thu Feb  7 15:46:31 2013
+From: elinsn at gmail.com (Sergey Yelin)
+Date: Thu, 7 Feb 2013 18:46:31 +0400
+Subject: [99s-extend] Big body via REST
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+ <[email protected]>
+Message-ID: <[email protected]>
+
+Ok, thanks.
+
+On Feb 7, 2013, at 6:41 PM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> On 02/07/2013 11:04 AM, Sergey Yelin wrote:
+>> Hi list,
+>> 
+>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+> 
+> Hey,
+> 
+> If you know the size, reply with {stream, Size, StreamFun}, otherwise {stream, StreamFun}, with StreamFun the function that will send all the data to the socket.
+> 
+> -- 
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+---
+Best regards,
+Sergey Yelin.
+
+
+
+
+
+From john at jkemp.net  Fri Feb  8 14:08:24 2013
+From: john at jkemp.net (John Kemp)
+Date: Fri, 08 Feb 2013 08:08:24 -0500
+Subject: [99s-extend] How to send multiple messages in response to one
+	message from Cowboy
+Message-ID: <[email protected]>
+
+Hi,
+
+I see that with websocket_info/3 I can prompt Cowboy to send a message 
+to a connected client by sending a "system message".
+
+How can I send multiple reply messages to a client which has sent a request?
+
+Is the way to do that by calling websocket_info/3 directly (multiple 
+times) from within my websocket_handle call?
+
+Cheers,
+
+JohnK
+
+
+From john at jkemp.net  Fri Feb  8 19:34:36 2013
+From: john at jkemp.net (John Kemp)
+Date: Fri, 08 Feb 2013 13:34:36 -0500
+Subject: [99s-extend] How to send multiple messages in response to one
+ message from Cowboy
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <[email protected]>
+
+Answering my own question - multiple messages can be sent in reply by 
+including a list of 'reply' tuples in the websocket_handle response. I 
+found this by looking at cowboy_websocket_handler.erl in the source tree.
+
+-callback websocket_handle({text | binary | ping | pong, binary()}, Req, 
+State)
+	-> {ok, Req, State}
+	| {ok, Req, State, hibernate}
+
+	| {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, 
+State}
+	| {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, 
+State, hibernate}
+
+	| {shutdown, Req, State}
+	when Req::cowboy_req:req(), State::state().
+
+JohnK
+
+On 02/08/2013 08:08 AM, John Kemp wrote:
+> Hi,
+>
+> I see that with websocket_info/3 I can prompt Cowboy to send a message
+> to a connected client by sending a "system message".
+>
+> How can I send multiple reply messages to a client which has sent a
+> request?
+>
+> Is the way to do that by calling websocket_info/3 directly (multiple
+> times) from within my websocket_handle call?
+>
+> Cheers,
+>
+> JohnK
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+From bip at kivra.com  Sun Feb 10 20:12:27 2013
+From: bip at kivra.com (Bip Thelin)
+Date: Sun, 10 Feb 2013 20:12:27 +0100
+Subject: [99s-extend] Cowboy questions
+Message-ID: <[email protected]>
+
+Hi,
+
+ I'm playing around with a middleware and request/responsehooks. A couple of questions that have surfaced:
+* Say I map a module to "/my/path[...]" and then curl "/my/path/even/more/stuff". Is there a way to retrieve the "rest" of the matched path, i.e. like cowboy_req:path_info/1 but just the rest, not the total path. The result I want is: [<<"even">>, <<"more">>, <<"stuff">>].
+* I've been trying to use a responsehook to ensure that a default content-type is set if none is specified. Been trying with cowboy_req:reply, coboy_req:set_resp_headers, etc. It doesn't seem to work that well. What's the preferred way?
+
+Regards,
+-Bip Thelin
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130210/1b9560c2/attachment.html>
+
+From essen at ninenines.eu  Tue Feb 12 18:36:12 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Tue, 12 Feb 2013 18:36:12 +0100
+Subject: [99s-extend] [ANN] Cowboy 0.8.0
+Message-ID: <[email protected]>
+
+Hello there!
+
+Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, 
+REST and Websocket server.
+
+   https://github.com/extend/cowboy/
+
+The number of contributors who helped make this release considerably 
+increased. Cowboy is available thanks to the code contributions from 50 
+users, double from the last release where 25 contributed.
+
+The number of users has also greatly increased. Cowboy is being used in 
+ad bidding, set-top boxes, live TV events, content streaming services, 
+and many more exciting areas.
+
+This new version has many highlights. You can take a look at the 
+changelog for detailed information about the many changes.
+
+   https://github.com/extend/cowboy/blob/master/CHANGELOG.md
+
+Cowboy scalability has been greatly improved in this version. This has 
+been observed many times in production, including in the AdGear Tracker 
+project (http://ferd.ca/rtb-where-erlang-blooms.html) where updated 
+nodes were able to handle 2 times more requests compared to older nodes. 
+This improvement cannot be observed in "hello world" types of 
+benchmarks. An article will soon be published to explain the reasons for 
+this.
+
+Cowboy now features a brand new user guide. It is still a work in 
+progress, so please open a ticket on Github if something is missing or 
+incorrect.
+
+   http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction
+
+Remaining work before 1.0 include REST improvements and SPDY support. 
+The rest of the API should now be very close to stable.
+
+I am looking for a good writer who would like to co-author a Cowboy 
+book. The book will be accessible to people who don't know Erlang but 
+will also contain everything there is to know about Cowboy, making it 
+suitable for both beginners and experts. Contact me if you are interested.
+
+I now take donations in addition to commercial support options, to allow 
+individual users to help the project stay alive and kicking.
+
+   http://ninenines.eu/support
+
+Hope you enjoy it. As always, please send me as much feedback as 
+possible to help me improve things even more, preferrably through Github 
+tickets if it's related to code or documentation.
+
+Thanks for reading.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From jeremy at quarkgames.com  Tue Feb 12 18:37:18 2013
+From: jeremy at quarkgames.com (Jeremy Ong)
+Date: Tue, 12 Feb 2013 09:37:18 -0800
+Subject: [99s-extend] [ANN] Cowboy 0.8.0
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <CAKD1GY5BkoTPtZrPhsp7hoWvXPKfqLX4-SKHzs6ecZ12KrRJMA@mail.gmail.com>
+
+Congrats!
+
+
+On Tue, Feb 12, 2013 at 9:36 AM, Lo?c Hoguin <essen at ninenines.eu> wrote:
+
+> Hello there!
+>
+> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP,
+> REST and Websocket server.
+>
+>   https://github.com/extend/**cowboy/ <https://github.com/extend/cowboy/>
+>
+> The number of contributors who helped make this release considerably
+> increased. Cowboy is available thanks to the code contributions from 50
+> users, double from the last release where 25 contributed.
+>
+> The number of users has also greatly increased. Cowboy is being used in ad
+> bidding, set-top boxes, live TV events, content streaming services, and
+> many more exciting areas.
+>
+> This new version has many highlights. You can take a look at the changelog
+> for detailed information about the many changes.
+>
+>   https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md<https://github.com/extend/cowboy/blob/master/CHANGELOG.md>
+>
+> Cowboy scalability has been greatly improved in this version. This has
+> been observed many times in production, including in the AdGear Tracker
+> project (http://ferd.ca/rtb-where-**erlang-blooms.html<http://ferd.ca/rtb-where-erlang-blooms.html>)
+> where updated nodes were able to handle 2 times more requests compared to
+> older nodes. This improvement cannot be observed in "hello world" types of
+> benchmarks. An article will soon be published to explain the reasons for
+> this.
+>
+> Cowboy now features a brand new user guide. It is still a work in
+> progress, so please open a ticket on Github if something is missing or
+> incorrect.
+>
+>   http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction<http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction>
+>
+> Remaining work before 1.0 include REST improvements and SPDY support. The
+> rest of the API should now be very close to stable.
+>
+> I am looking for a good writer who would like to co-author a Cowboy book.
+> The book will be accessible to people who don't know Erlang but will also
+> contain everything there is to know about Cowboy, making it suitable for
+> both beginners and experts. Contact me if you are interested.
+>
+> I now take donations in addition to commercial support options, to allow
+> individual users to help the project stay alive and kicking.
+>
+>   http://ninenines.eu/support
+>
+> Hope you enjoy it. As always, please send me as much feedback as possible
+> to help me improve things even more, preferrably through Github tickets if
+> it's related to code or documentation.
+>
+> Thanks for reading.
+>
+> --
+> 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/20130212/09008370/attachment.html>
+
+From max.lapshin at gmail.com  Tue Feb 12 18:44:28 2013
+From: max.lapshin at gmail.com (Max Lapshin)
+Date: Tue, 12 Feb 2013 20:44:28 +0300
+Subject: [99s-extend] [erlang-questions]  [ANN] Cowboy 0.8.0
+In-Reply-To: <CAKD1GY5BkoTPtZrPhsp7hoWvXPKfqLX4-SKHzs6ecZ12KrRJMA@mail.gmail.com>
+References: <[email protected]>
+ <CAKD1GY5BkoTPtZrPhsp7hoWvXPKfqLX4-SKHzs6ecZ12KrRJMA@mail.gmail.com>
+Message-ID: <CAMxVRxAREhN_WmD-__STe_VG6hS_RNoy9VAN0TwwHG9wJ1AYEg@mail.gmail.com>
+
+Great, Loic.
+
+As I've told already, it would be great to listen to your experience about
+issues that you meet on high loads: smooth scaling, predictionable
+behaviour of server, etc.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130212/dc0291b4/attachment.html>
+
+From Christopher.Phillips at turner.com  Wed Feb 13 14:52:10 2013
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Wed, 13 Feb 2013 13:52:10 +0000
+Subject: [99s-extend] Cowboy REST Logic
+Message-ID: <CD41053B.266D%[email protected]>
+
+
+  In 6.1, and still in 8.0, there is some logic that surprised me, and I wanted to see if it was intentional, or if I'm missing something.
+
+  If I set up a POST such that it's a create, I get back a 303, rather than a 201, on successful create. This came as a bit of a surprise; I know from Webmachine, if it's a new resource being created, a POST will return a 201 (N11 to P11 in Webmachine's v3 diagram).
+
+  Is this intentional? The logic seems to be post_is_create/2 -> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> respond(_, _, 303). It may be that this is a better response, rather than a 201 with the location header, but it came as a surprise given web machine's behavior.
+
+  For background, I'm attempting to migrate some web machine code to Cowboy, which is serving a RESTful API to a Javascript client. The client is making CORS calls. Receiving a 303 and a Location header seemed to mean that the call was redirected before the client side code ever saw it (not sure what the browser was doing; I was expecting another request, but I wasn't quite lucid enough to check for that last night when working on it); a 201 allows me to examine the location.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130213/a992c0b6/attachment.html>
+
+From gumm at sigma-star.com  Wed Feb 13 14:46:07 2013
+From: gumm at sigma-star.com (Jesse Gumm)
+Date: Wed, 13 Feb 2013 07:46:07 -0600
+Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0
+In-Reply-To: <[email protected]>
+References: <[email protected]>
+Message-ID: <CAPTXyXd9BYynUj5Tp8Mmk7uL8VEByQHSwJZ_20Q-gkZEz=J=Kg@mail.gmail.com>
+
+Great news!
+
+Congrats!
+On Feb 12, 2013 11:36 AM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+
+> Hello there!
+>
+> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP,
+> REST and Websocket server.
+>
+>   https://github.com/extend/**cowboy/ <https://github.com/extend/cowboy/>
+>
+> The number of contributors who helped make this release considerably
+> increased. Cowboy is available thanks to the code contributions from 50
+> users, double from the last release where 25 contributed.
+>
+> The number of users has also greatly increased. Cowboy is being used in ad
+> bidding, set-top boxes, live TV events, content streaming services, and
+> many more exciting areas.
+>
+> This new version has many highlights. You can take a look at the changelog
+> for detailed information about the many changes.
+>
+>   https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md<https://github.com/extend/cowboy/blob/master/CHANGELOG.md>
+>
+> Cowboy scalability has been greatly improved in this version. This has
+> been observed many times in production, including in the AdGear Tracker
+> project (http://ferd.ca/rtb-where-**erlang-blooms.html<http://ferd.ca/rtb-where-erlang-blooms.html>)
+> where updated nodes were able to handle 2 times more requests compared to
+> older nodes. This improvement cannot be observed in "hello world" types of
+> benchmarks. An article will soon be published to explain the reasons for
+> this.
+>
+> Cowboy now features a brand new user guide. It is still a work in
+> progress, so please open a ticket on Github if something is missing or
+> incorrect.
+>
+>   http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction<http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction>
+>
+> Remaining work before 1.0 include REST improvements and SPDY support. The
+> rest of the API should now be very close to stable.
+>
+> I am looking for a good writer who would like to co-author a Cowboy book.
+> The book will be accessible to people who don't know Erlang but will also
+> contain everything there is to know about Cowboy, making it suitable for
+> both beginners and experts. Contact me if you are interested.
+>
+> I now take donations in addition to commercial support options, to allow
+> individual users to help the project stay alive and kicking.
+>
+>   http://ninenines.eu/support
+>
+> Hope you enjoy it. As always, please send me as much feedback as possible
+> to help me improve things even more, preferrably through Github tickets if
+> it's related to code or documentation.
+>
+> Thanks for reading.
+>
+> --
+> Lo?c Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130213/41b12a6d/attachment.html>
+
+From essen at ninenines.eu  Wed Feb 13 16:34:54 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Wed, 13 Feb 2013 16:34:54 +0100
+Subject: [99s-extend] Cowboy REST Logic
+In-Reply-To: <CD41053B.266D%[email protected]>
+References: <CD41053B.266D%[email protected]>
+Message-ID: <[email protected]>
+
+On 02/13/2013 02:52 PM, Phillips, Christopher wrote:
+>
+>    In 6.1, and still in 8.0, there is some logic that surprised me, and
+> I wanted to see if it was intentional, or if I'm missing something.
+>
+>    If I set up a POST such that it's a create, I get back a 303, rather
+> than a 201, on successful create. This came as a bit of a surprise; I
+> know from Webmachine, if it's a new resource being created, a POST will
+> return a 201 (N11 to P11 in Webmachine's v3 diagram).
+>
+>    Is this intentional? The logic seems to be post_is_create/2 ->
+> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 ->
+> respond(_, _, 303). It may be that this is a better response, rather
+> than a 201 with the location header, but it came as a surprise given web
+> machine's behavior.
+
+This difference is probably not intentional. Please open a ticket. :)
+
+>    For background, I'm attempting to migrate some web machine code to
+> Cowboy, which is serving a RESTful API to a Javascript client. The
+> client is making CORS calls. Receiving a 303 and a Location header
+> seemed to mean that the call was redirected before the client side code
+> ever saw it (not sure what the browser was doing; I was expecting
+> another request, but I wasn't quite lucid enough to check for that last
+> night when working on it); a 201 allows me to examine the location.
+
+Would be interested to know more about your CORS implementation, that's 
+something I would like to have in the guide.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From Christopher.Phillips at turner.com  Wed Feb 13 17:01:27 2013
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Wed, 13 Feb 2013 16:01:27 +0000
+Subject: [99s-extend] Cowboy REST Logic
+In-Reply-To: <[email protected]>
+Message-ID: <CD411D79.2699%[email protected]>
+
+  Will do. I actually like the 303 due to a bug in Firefox with examining
+headers, but 201 seems like the canonical approach.
+  
+  CORS is actually pretty easy to open up fully, and the more restrictive
+you want to be the harder it gets. We're not using credentials, and we
+haven't tightened the domain to just those we expect, either, but it
+basically amounts to adding the following to options/2 for the pre-flight -
+
+  * Access-Control-Allow-Origin (with the origins we want to allow; * for
+anything), 
+  * Access-Control-Allow-Headers (which we're setting to the same as the
+client requests for convenience's sake)
+  *Access-Control-Expose-Headers (for any headers beyond content-type that
+the client wants access to; we have Location for the 201 mentioned above.
+
+
+And the following to any request being passed back, as seems reasonable -
+
+  * Access-Control-Allow-Origin as in options
+  * Access-Control-Expose-Headers as in options
+
+
+ I'm appending them in resource_exists/2 because I know that will be hit
+by everything. If your logic is more complex (you want to allow PUTs from
+site1, but deletes from site2, etc), you'll need to break that apart a bit
+and conditionally check origin. We're relying on a firewall to protect
+against direct calls from external servers, and we'll be tightening the
+allowed domains and looking into validating the session with a token to
+prevent CSRFs (as CORS means any existing CSRF vuln becomes a bit more
+severe). 
+
+
+I suspect there's some redundancy there; we have a future story for
+tightening things up, but in terms of just opening it up and getting
+things working, that?s all that I had to do.
+
+
+On 2/13/13 10:34 AM, "Lo?c Hoguin" <essen at ninenines.eu> wrote:
+
+>On 02/13/2013 02:52 PM, Phillips, Christopher wrote:
+>>
+>>    In 6.1, and still in 8.0, there is some logic that surprised me, and
+>> I wanted to see if it was intentional, or if I'm missing something.
+>>
+>>    If I set up a POST such that it's a create, I get back a 303, rather
+>> than a 201, on successful create. This came as a bit of a surprise; I
+>> know from Webmachine, if it's a new resource being created, a POST will
+>> return a 201 (N11 to P11 in Webmachine's v3 diagram).
+>>
+>>    Is this intentional? The logic seems to be post_is_create/2 ->
+>> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 ->
+>> respond(_, _, 303). It may be that this is a better response, rather
+>> than a 201 with the location header, but it came as a surprise given web
+>> machine's behavior.
+>
+>This difference is probably not intentional. Please open a ticket. :)
+>
+>>    For background, I'm attempting to migrate some web machine code to
+>> Cowboy, which is serving a RESTful API to a Javascript client. The
+>> client is making CORS calls. Receiving a 303 and a Location header
+>> seemed to mean that the call was redirected before the client side code
+>> ever saw it (not sure what the browser was doing; I was expecting
+>> another request, but I wasn't quite lucid enough to check for that last
+>> night when working on it); a 201 allows me to examine the location.
+>
+>Would be interested to know more about your CORS implementation, that's
+>something I would like to have in the guide.
+>
+>-- 
+>Lo?c Hoguin
+>Erlang Cowboy
+>Nine Nines
+>http://ninenines.eu
+>
+
+
+
+
+From essen at ninenines.eu  Thu Feb 14 17:29:23 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Thu, 14 Feb 2013 17:29:23 +0100
+Subject: [99s-extend] [ANN] Bullet 0.4.0
+Message-ID: <[email protected]>
+
+Quick announcement: Bullet 0.4.0 has been released. This version is 
+compatible with newly released Cowboy 0.8.0.
+
+   https://github.com/extend/bullet
+
+Bullet is a simple and efficient Websocket alternative especially useful 
+when you need an always connected socket to the server. It uses 
+Websocket internally when it's available.
+
+Enjoy!
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From list1 at gjunka.com  Mon Feb 18 17:01:30 2013
+From: list1 at gjunka.com (Grzegorz Junka)
+Date: Mon, 18 Feb 2013 16:01:30 +0000
+Subject: [99s-extend] sub_description is not a valid app configuration option
+Message-ID: <[email protected]>
+
+Hi,
+I am trying to compile a release with some applications for which ranch 
+and cowboy are dependencies. This is what I am getting on the console:
+
+reltool: Unexpected item sub_description in app file 
+"/usr/home/somepath/deps/ranch/ebin/ranch.app".
+reltool: Unexpected item sub_description in app file 
+"/usr/home/somepath/deps/cowboy/ebin/cowboy.app".
+
+When looking it up on Erlang documentation it seems that sub_description 
+is not a valid configuration options in the .app file. Is there any 
+chance to put it rather as a comment?
+
+
+
+From essen at ninenines.eu  Wed Feb 20 19:58:31 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Wed, 20 Feb 2013 19:58:31 +0100
+Subject: [99s-extend] [ANN] Bullet 0.4.1
+Message-ID: <[email protected]>
+
+Version update to fix a bug that broke POST with non-Websocket transports.
+
+Enjoy!
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From Christopher.Phillips at turner.com  Thu Feb 21 20:29:36 2013
+From: Christopher.Phillips at turner.com (Phillips, Christopher)
+Date: Thu, 21 Feb 2013 19:29:36 +0000
+Subject: [99s-extend] Arbitrary 500 from REST handler?
+Message-ID: <CD4BDFCE.2D43%[email protected]>
+
+
+  I have a case where I am creating a resource through a POST. There are a number of places where the create can fail in a known manner, and we need to alert the user to the specifics of why. Is there a way to throw an arbitrary 500, with message, from within the REST handler? I can obviously just erlang:error(whatever), but the message content is ignored, and there is no way to pass back an updated response when doing that.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130221/fc119c69/attachment.html>
+
+From essen at ninenines.eu  Thu Feb 21 20:38:35 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Thu, 21 Feb 2013 20:38:35 +0100
+Subject: [99s-extend] Arbitrary 500 from REST handler?
+In-Reply-To: <CD4BDFCE.2D43%[email protected]>
+References: <CD4BDFCE.2D43%[email protected]>
+Message-ID: <[email protected]>
+
+On 02/21/2013 08:29 PM, Phillips, Christopher wrote:
+>
+>    I have a case where I am creating a resource through a POST. There
+> are a number of places where the create can fail in a known manner, and
+> we need to alert the user to the specifics of why. Is there a way to
+> throw an arbitrary 500, with message, from within the REST handler? I
+> can obviously just erlang:error(whatever), but the message content is
+> ignored, and there is no way to pass back an updated response when doing
+> that.
+
+Use cowboy_req:reply and then return {halt, Req2, State} to stop execution.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From essen at ninenines.eu  Fri Feb 22 15:41:58 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Fri, 22 Feb 2013 15:41:58 +0100
+Subject: [99s-extend] Cowboy 0.8.1
+Message-ID: <[email protected]>
+
+Just tagged Cowboy 0.8.1.
+
+   https://github.com/extend/cowboy/
+
+Please see the CHANGELOG.md file.
+
+I am hoping to tag a new minor version every couple weeks now that the 
+bigger API changes have been done.
+
+Next version should have the remaining REST API changes, bringing it 
+much closer to being stable, with only additions planned subsequently.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+From essen at ninenines.eu  Sat Feb 23 16:52:47 2013
+From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=)
+Date: Sat, 23 Feb 2013 16:52:47 +0100
+Subject: [99s-extend] Directory traversal vulnerability on Windows platform
+Message-ID: <[email protected]>
+
+A directory traversal vulnerability affecting all Windows platforms has 
+been discovered. Please follow these instructions to find out if you are 
+affected. Please take immediate action if you are.
+
+### Am I affected?
+
+You are if you match all of the following requirements:
+
+  *  You run Cowboy in production on the Windows platform
+  *  You make use of `cowboy_static` (or `cowboy_http_static` in older 
+versions)
+
+### How serious is it?
+
+This vulnerability allows an attacker to request any file from your 
+system (only limited by the access rights of the user running the Erlang 
+VM). The attacker cannot list files through this vulnerability. This 
+however does not reduce the seriousness of this vulnerability as an 
+attacker can always use brute force or any other method to try to find 
+files on your system.
+
+### How can I fix it?
+
+No patch is currently available.
+
+You should temporarily switch to using IIS or any other web server for 
+serving the static files, or use a CDN instead.
+
+### How can I make sure this will not happen again?
+
+A fully cross-platform fix will be pushed to Cowboy in the coming days.
+
+This issue exists essentially because Windows isn't a supported platform 
+and we do not have the resources or knowledge to make the Windows 
+experience safe and smooth.
+
+If you are a Windows user, you can ensure that kind of issue does not 
+happen again by becoming a regular contributor and making sure the team 
+is aware of any potential issue that may arise on Windows.
+
+### Why disclose?
+
+Essentially for three reasons:
+
+  *  Considering the known user base, a very low number of people might 
+be hit by this issue
+  *  A temporary fix is readily available
+  *  Community help is needed to ensure a proper fix gets merged
+
+The following ticket can be used for tracking this issue:
+
+   https://github.com/extend/cowboy/issues/447
+
+Please ping this ticket if you are affected. Ignore if you are not. Thanks.
+
+-- 
+Lo?c Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+