From c807880f7ac73f813b2660ea81a00f7712a4e793 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Mon, 29 Aug 2016 12:39:49 +0200 Subject: Add old mailing list archives --- archives/extend/2013-February/000043.html | 93 +++++++++++++ archives/extend/2013-February/000044.html | 115 ++++++++++++++++ archives/extend/2013-February/000045.html | 134 +++++++++++++++++++ archives/extend/2013-February/000046.html | 69 ++++++++++ archives/extend/2013-February/000047.html | 77 +++++++++++ archives/extend/2013-February/000048.html | 86 ++++++++++++ archives/extend/2013-February/000049.html | 74 +++++++++++ archives/extend/2013-February/000050.html | 100 ++++++++++++++ archives/extend/2013-February/000051.html | 72 ++++++++++ archives/extend/2013-February/000052.html | 119 +++++++++++++++++ archives/extend/2013-February/000053.html | 131 ++++++++++++++++++ archives/extend/2013-February/000054.html | 68 ++++++++++ archives/extend/2013-February/000055.html | 71 ++++++++++ archives/extend/2013-February/000056.html | 131 ++++++++++++++++++ archives/extend/2013-February/000057.html | 95 +++++++++++++ archives/extend/2013-February/000058.html | 137 +++++++++++++++++++ archives/extend/2013-February/000059.html | 77 +++++++++++ archives/extend/2013-February/000060.html | 74 +++++++++++ archives/extend/2013-February/000061.html | 70 ++++++++++ archives/extend/2013-February/000062.html | 65 +++++++++ archives/extend/2013-February/000063.html | 78 +++++++++++ archives/extend/2013-February/000064.html | 78 +++++++++++ archives/extend/2013-February/000065.html | 119 +++++++++++++++++ archives/extend/2013-February/author.html | 162 +++++++++++++++++++++++ archives/extend/2013-February/date.html | 162 +++++++++++++++++++++++ archives/extend/2013-February/index.html | 205 +++++++++++++++++++++++++++++ archives/extend/2013-February/subject.html | 162 +++++++++++++++++++++++ archives/extend/2013-February/thread.html | 205 +++++++++++++++++++++++++++++ 28 files changed, 3029 insertions(+) create mode 100644 archives/extend/2013-February/000043.html create mode 100644 archives/extend/2013-February/000044.html create mode 100644 archives/extend/2013-February/000045.html create mode 100644 archives/extend/2013-February/000046.html create mode 100644 archives/extend/2013-February/000047.html create mode 100644 archives/extend/2013-February/000048.html create mode 100644 archives/extend/2013-February/000049.html create mode 100644 archives/extend/2013-February/000050.html create mode 100644 archives/extend/2013-February/000051.html create mode 100644 archives/extend/2013-February/000052.html create mode 100644 archives/extend/2013-February/000053.html create mode 100644 archives/extend/2013-February/000054.html create mode 100644 archives/extend/2013-February/000055.html create mode 100644 archives/extend/2013-February/000056.html create mode 100644 archives/extend/2013-February/000057.html create mode 100644 archives/extend/2013-February/000058.html create mode 100644 archives/extend/2013-February/000059.html create mode 100644 archives/extend/2013-February/000060.html create mode 100644 archives/extend/2013-February/000061.html create mode 100644 archives/extend/2013-February/000062.html create mode 100644 archives/extend/2013-February/000063.html create mode 100644 archives/extend/2013-February/000064.html create mode 100644 archives/extend/2013-February/000065.html create mode 100644 archives/extend/2013-February/author.html create mode 100644 archives/extend/2013-February/date.html create mode 100644 archives/extend/2013-February/index.html create mode 100644 archives/extend/2013-February/subject.html create mode 100644 archives/extend/2013-February/thread.html (limited to 'archives/extend/2013-February') diff --git a/archives/extend/2013-February/000043.html b/archives/extend/2013-February/000043.html new file mode 100644 index 00000000..36cbddbd --- /dev/null +++ b/archives/extend/2013-February/000043.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Jeremy Ong + jeremy at quarkgames.com +
+ Mon Feb 4 21:10:21 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000044.html b/archives/extend/2013-February/000044.html new file mode 100644 index 00000000..303f2249 --- /dev/null +++ b/archives/extend/2013-February/000044.html @@ -0,0 +1,115 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Grzegorz Junka + list1 at gjunka.com +
+ Mon Feb 4 22:50:14 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000045.html b/archives/extend/2013-February/000045.html new file mode 100644 index 00000000..4e04e930 --- /dev/null +++ b/archives/extend/2013-February/000045.html @@ -0,0 +1,134 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 4 22:58:39 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000046.html b/archives/extend/2013-February/000046.html new file mode 100644 index 00000000..eae5ae9f --- /dev/null +++ b/archives/extend/2013-February/000046.html @@ -0,0 +1,69 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Sergey Yelin + elinsn at gmail.com +
+ Thu Feb 7 11:04:05 CET 2013 +

+
+ +
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.
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000047.html b/archives/extend/2013-February/000047.html new file mode 100644 index 00000000..4cc75a92 --- /dev/null +++ b/archives/extend/2013-February/000047.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 7 15:41:03 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000048.html b/archives/extend/2013-February/000048.html new file mode 100644 index 00000000..62ddba81 --- /dev/null +++ b/archives/extend/2013-February/000048.html @@ -0,0 +1,86 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Sergey Yelin + elinsn at gmail.com +
+ Thu Feb 7 15:46:31 CET 2013 +

+
+ +
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.
+
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000049.html b/archives/extend/2013-February/000049.html new file mode 100644 index 00000000..9a5040ee --- /dev/null +++ b/archives/extend/2013-February/000049.html @@ -0,0 +1,74 @@ + + + + [99s-extend] How to send multiple messages in response to one message from Cowboy + + + + + + + + + + +

[99s-extend] How to send multiple messages in response to one message from Cowboy

+ John Kemp + john at jkemp.net +
+ Fri Feb 8 14:08:24 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000050.html b/archives/extend/2013-February/000050.html new file mode 100644 index 00000000..23828af8 --- /dev/null +++ b/archives/extend/2013-February/000050.html @@ -0,0 +1,100 @@ + + + + [99s-extend] How to send multiple messages in response to one message from Cowboy + + + + + + + + + + +

[99s-extend] How to send multiple messages in response to one message from Cowboy

+ John Kemp + john at jkemp.net +
+ Fri Feb 8 19:34:36 CET 2013 +

+
+ +
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
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000051.html b/archives/extend/2013-February/000051.html new file mode 100644 index 00000000..01827233 --- /dev/null +++ b/archives/extend/2013-February/000051.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Cowboy questions + + + + + + + + + + +

[99s-extend] Cowboy questions

+ Bip Thelin + bip at kivra.com +
+ Sun Feb 10 20:12:27 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000052.html b/archives/extend/2013-February/000052.html new file mode 100644 index 00000000..c2171e9a --- /dev/null +++ b/archives/extend/2013-February/000052.html @@ -0,0 +1,119 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Feb 12 18:36:12 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000053.html b/archives/extend/2013-February/000053.html new file mode 100644 index 00000000..d8c5ac05 --- /dev/null +++ b/archives/extend/2013-February/000053.html @@ -0,0 +1,131 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.0

+ Jeremy Ong + jeremy at quarkgames.com +
+ Tue Feb 12 18:37:18 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000054.html b/archives/extend/2013-February/000054.html new file mode 100644 index 00000000..29525584 --- /dev/null +++ b/archives/extend/2013-February/000054.html @@ -0,0 +1,68 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0

+ Max Lapshin + max.lapshin at gmail.com +
+ Tue Feb 12 18:44:28 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000055.html b/archives/extend/2013-February/000055.html new file mode 100644 index 00000000..9d3e7817 --- /dev/null +++ b/archives/extend/2013-February/000055.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Wed Feb 13 14:52:10 CET 2013 +

+
+ +
+  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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000056.html b/archives/extend/2013-February/000056.html new file mode 100644 index 00000000..1a6087c9 --- /dev/null +++ b/archives/extend/2013-February/000056.html @@ -0,0 +1,131 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0

+ Jesse Gumm + gumm at sigma-star.com +
+ Wed Feb 13 14:46:07 CET 2013 +

+
+ +
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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000057.html b/archives/extend/2013-February/000057.html new file mode 100644 index 00000000..9a7004d5 --- /dev/null +++ b/archives/extend/2013-February/000057.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Feb 13 16:34:54 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000058.html b/archives/extend/2013-February/000058.html new file mode 100644 index 00000000..2f44c8c7 --- /dev/null +++ b/archives/extend/2013-February/000058.html @@ -0,0 +1,137 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Wed Feb 13 17:01:27 CET 2013 +

+
+ +
  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
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000059.html b/archives/extend/2013-February/000059.html new file mode 100644 index 00000000..edd489c4 --- /dev/null +++ b/archives/extend/2013-February/000059.html @@ -0,0 +1,77 @@ + + + + [99s-extend] [ANN] Bullet 0.4.0 + + + + + + + + + + +

[99s-extend] [ANN] Bullet 0.4.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 14 17:29:23 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000060.html b/archives/extend/2013-February/000060.html new file mode 100644 index 00000000..0e16e401 --- /dev/null +++ b/archives/extend/2013-February/000060.html @@ -0,0 +1,74 @@ + + + + [99s-extend] sub_description is not a valid app configuration option + + + + + + + + + + +

[99s-extend] sub_description is not a valid app configuration option

+ Grzegorz Junka + list1 at gjunka.com +
+ Mon Feb 18 17:01:30 CET 2013 +

+
+ +
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?
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000061.html b/archives/extend/2013-February/000061.html new file mode 100644 index 00000000..c737d54e --- /dev/null +++ b/archives/extend/2013-February/000061.html @@ -0,0 +1,70 @@ + + + + [99s-extend] [ANN] Bullet 0.4.1 + + + + + + + + + + +

[99s-extend] [ANN] Bullet 0.4.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Feb 20 19:58:31 CET 2013 +

+
+ +
Version update to fix a bug that broke POST with non-Websocket transports.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000062.html b/archives/extend/2013-February/000062.html new file mode 100644 index 00000000..077c5e97 --- /dev/null +++ b/archives/extend/2013-February/000062.html @@ -0,0 +1,65 @@ + + + + [99s-extend] Arbitrary 500 from REST handler? + + + + + + + + + + +

[99s-extend] Arbitrary 500 from REST handler?

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Thu Feb 21 20:29:36 CET 2013 +

+
+ +
+  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>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000063.html b/archives/extend/2013-February/000063.html new file mode 100644 index 00000000..bfebf6d7 --- /dev/null +++ b/archives/extend/2013-February/000063.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Arbitrary 500 from REST handler? + + + + + + + + + + +

[99s-extend] Arbitrary 500 from REST handler?

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 21 20:38:35 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000064.html b/archives/extend/2013-February/000064.html new file mode 100644 index 00000000..89b3839d --- /dev/null +++ b/archives/extend/2013-February/000064.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Cowboy 0.8.1 + + + + + + + + + + +

[99s-extend] Cowboy 0.8.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Feb 22 15:41:58 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/000065.html b/archives/extend/2013-February/000065.html new file mode 100644 index 00000000..8747e30f --- /dev/null +++ b/archives/extend/2013-February/000065.html @@ -0,0 +1,119 @@ + + + + [99s-extend] Directory traversal vulnerability on Windows platform + + + + + + + + + + +

[99s-extend] Directory traversal vulnerability on Windows platform

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Feb 23 16:52:47 CET 2013 +

+
+ +
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
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/archives/extend/2013-February/author.html b/archives/extend/2013-February/author.html new file mode 100644 index 00000000..a21788bd --- /dev/null +++ b/archives/extend/2013-February/author.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by author + + + + + +

February 2013 Archives by author

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/archives/extend/2013-February/date.html b/archives/extend/2013-February/date.html new file mode 100644 index 00000000..07cd4de8 --- /dev/null +++ b/archives/extend/2013-February/date.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by date + + + + + +

February 2013 Archives by date

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/archives/extend/2013-February/index.html b/archives/extend/2013-February/index.html new file mode 100644 index 00000000..4dc2b5dd --- /dev/null +++ b/archives/extend/2013-February/index.html @@ -0,0 +1,205 @@ + + + + The Extend February 2013 Archive by thread + + + + + +

February 2013 Archives by thread

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/archives/extend/2013-February/subject.html b/archives/extend/2013-February/subject.html new file mode 100644 index 00000000..3402dfab --- /dev/null +++ b/archives/extend/2013-February/subject.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by subject + + + + + +

February 2013 Archives by subject

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/archives/extend/2013-February/thread.html b/archives/extend/2013-February/thread.html new file mode 100644 index 00000000..4dc2b5dd --- /dev/null +++ b/archives/extend/2013-February/thread.html @@ -0,0 +1,205 @@ + + + + The Extend February 2013 Archive by thread + + + + + +

February 2013 Archives by thread

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.3