diff options
Diffstat (limited to '_build/static/archives/extend/2013-February.txt')
-rw-r--r-- | _build/static/archives/extend/2013-February.txt | 948 |
1 files changed, 948 insertions, 0 deletions
diff --git a/_build/static/archives/extend/2013-February.txt b/_build/static/archives/extend/2013-February.txt new file mode 100644 index 00000000..7a325ec7 --- /dev/null +++ b/_build/static/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> +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]> +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 + + |