<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel">
    <title>gmane.comp.networking.cpp-netlib.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2235"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2234"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2233"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2232"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2231"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2230"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2229"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2228"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2227"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2226"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2225"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2224"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2223"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2222"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2221"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2220"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2219"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2218"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2217"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2216"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2235">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2235</link>
    <description>&lt;pre&gt;On Wed, May 22, 2013 at 1:18 AM, Nicola Bizzoca
&amp;lt;nicola.bizzoca-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

It could be, as the auth manager should determine it on a per-route basis. ;)


Not required for something like this. Policies is enough so far.


Why would you want a custom constructor to the session? The session
manager should populate the session object with the appropriate stuff.


Awesome, looking forward to seeing more pull requests from you! :)

&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-23T03:11:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2234">
    <title>Re: chunked transfer-encoding</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2234</link>
    <description>&lt;pre&gt;Interesting. Can you show what exactly the server is sending (using
something like tcpdump) and that cpp-netlib is really ignoring it?
Also, can you also send what the client is actually sending the
server?

On Wed, May 22, 2013 at 10:35 AM,  &amp;lt;shawnhe-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-23T01:57:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2233">
    <title>Re: setting custom callback</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2233</link>
    <description>&lt;pre&gt;
Look up how to use std::bind and/or boost::bind to do partial binding
(currying) of parameters to functions. Also think about using
boost::function or std::function to hold a copy of the user-defined
callback in your body callback handler -- remember this is code you
write, and the library doesn't have to concern itself with these
user-design level requirements.

I would do it this way: if you write your body_handler implementation
to take a completion callback that has a different signature in its
constructor, you can implement the incremental body handler to do
something similar to what you're doing now without having to use
global variables. You know the body is "done" when this incremental
body callback is called with an empty range and/or an error is
provided.

&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-23T01:22:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2232">
    <title>Re: setting custom callback</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2232</link>
    <description>&lt;pre&gt;I think what I ask really is to add a user data pointer in the current 
callback, and then pass it back in when the callback fires, that should 
allow the user to do whatever needed including fire his own callbacks. If 
you are too busy to make that change, I am willing to do that.

On Monday, May 20, 2013 3:38:22 PM UTC-7, sha...-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org wrote:

&lt;/pre&gt;</description>
    <dc:creator>shawnhe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T23:07:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2231">
    <title>Re: Using custom asio instance issue</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2231</link>
    <description>&lt;pre&gt;This problem is no longer an issue, as the code I worked on earlier didn't 
handle multithreads properly, and the code must be just sleeping in the 
wait loop indefinitely. Feel free to close this issue. Thanks.

On Monday, May 20, 2013 8:38:48 PM UTC-7, Dean Michael Berris wrote:

&lt;/pre&gt;</description>
    <dc:creator>shawnhe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T22:30:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2230">
    <title>Re: setting custom callback</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2230</link>
    <description>&lt;pre&gt;Here is my modified sample code:

#define BOOST_NETWORK_ENABLE_HTTPS
#include &amp;lt;boost/program_options.hpp&amp;gt;
#include &amp;lt;boost/network/protocol/http.hpp&amp;gt;
#include &amp;lt;string&amp;gt;
#include &amp;lt;utility&amp;gt;
#include &amp;lt;iostream&amp;gt;

namespace po = boost::program_options;
using namespace boost::network;

bool callback_fired = false;

typedef http::basic_client&amp;lt;http::tags::http_async_8bit_tcp_resolve, 1, 1&amp;gt;
        http_client;

http_client::response response;

struct body_handler {
    explicit body_handler(std::string &amp;amp; body)
    : body(body) {}

    BOOST_NETWORK_HTTP_BODY_CALLBACK(operator(), range, error) {
        // in here, range is the Boost.Range iterator_range, and error is
        // the Boost.System error code.
        if (!error)
            body.append(boost::begin(range), boost::end(range));

        if(ready(response) &amp;amp;&amp;amp; !callback_fired) {
            callback_fired = true;
    
            std::cout&amp;lt;&amp;lt;"callback fired"&amp;lt;&amp;lt;std::endl;
        }
    }

    std::string &amp;amp; body;
};

int main(int argc, char * argv[]) {

    po::&lt;/pre&gt;</description>
    <dc:creator>shawnhe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T22:20:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2229">
    <title>Re: chunked transfer-encoding</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2229</link>
    <description>&lt;pre&gt;Here is the output I got using curl command:

url https://www.google.com -I
HTTP/1.1 200 OK
Date: Wed, 22 May 2013 17:25:54 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: 
PREF=ID=13778836460ece5e:FF=0:TM=1369243554:LM=1369243554:S=7ABfwdaFwh5udme2; 
expires=Fri, 22-May-2015 17:25:54 GMT; path=/; domain=.google.com
Set-Cookie: 
NID=67=Tdzjtcy_GWjTPei1NFXwUuWhiTH2tmmapzttE-BtwgFuxmjAHayaYTKo-ysbLkpimvJvKOsrYDicCAcNoMIwlQpcvjMbLrwNN_gWpLAIdFVzcIfMlU9oiTpAMk6ZaQG1; 
expires=Thu, 21-Nov-2013 17:25:54 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See 
http://www.google.com/support/accounts/bin/answer.py?hl=en&amp;amp;answer=151657 
for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

The last line of the header is the Transfer-Encoding field.


Here is the output with the modified sample code:

./httpClient -H -s https://www.google.com
callback fired
Cache-Control: priva&lt;/pre&gt;</description>
    <dc:creator>shawnhe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T17:35:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2228">
    <title>Re: Compiling on windows</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2228</link>
    <description>&lt;pre&gt;As previously said, CPP-NETLIB.sln must be generated using cmake.

Assuming that you're in the root folder of cppnetlib and that cmake is in 
your PATH, run these:
mkdir msbuild
cd msbuild
cmake -G "Visual Studio 11" ..

Then you should see in the msbuild directory several .vcxproj files and 
CPP-NETLIB.sln.


Le mardi 23 avril 2013 23:05:28 UTC+2, Tom Lee a écrit :

&lt;/pre&gt;</description>
    <dc:creator>Nicolas F</dc:creator>
    <dc:date>2013-05-22T11:25:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2227">
    <title>Re: Contributing to http-server-rewrite</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2227</link>
    <description>&lt;pre&gt;Hi Nicola -- sorry about that, I've only mostly been working on this
offline and syncing very sparsely. I've pushed the latest now to the
branch and you should be able to use it now. Thanks for asking!

On Wed, May 22, 2013 at 6:56 PM, Nicola Bizzoca
&amp;lt;nicola.bizzoca-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-22T11:04:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2226">
    <title>Contributing to http-server-rewrite</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2226</link>
    <description>&lt;pre&gt;Hi,
As you know, I'm new to programming, but I want to contribute to netlib, so

Is http-server-rewrite updated? References to some file like 
http/server/connection.hpp that aren't present in the branch is a normal 
thing?

There are a TODO list?

&lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-22T08:56:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2225">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2225</link>
    <description>&lt;pre&gt;Il giorno mercoledì 22 maggio 2013 09:40:45 UTC+2, Dean Michael Berris ha 
scritto:
Ok, I will think about it
Another thing that I was thinking is "Why auth is server global policy? 
Can't be made route specific?"
I was thinking about 
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern



The problem is that from the api of session I view that is constructed for 
every request, so how I can specify a custom constructor?
 


Ok, now is more clear

I will try to write some code

I'm learning C++ thanks to netlib :-P
 

&lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-22T08:18:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2224">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2224</link>
    <description>&lt;pre&gt;On Wed, May 22, 2013 at 12:11 AM, Nicola Bizzoca
&amp;lt;nicola.bizzoca-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

In this case sessions refer to user sessions -- usually those that are
characterized by "cookies" or a user's session. A session manager will
implement the required connections to databases and can be initialized
externally -- yes, it should be possible to inject the things the
session manager requires when you construct a server that takes a
specific kind of session manager.

You can also implement a "null" session manager which just returns a
null session object everytime (indicating that the server does not
support sessions).


What is the problem here exactly?


Easy, through the basic_server constructor. It will take options, and
part of the options will be shared pointers to the policy instances.

The default policies are there for the case when a basic_server was
constructed without passing in the specific policy instances -- so
that it can (default) construct the instance of the policy to&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-22T07:40:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2223">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2223</link>
    <description>&lt;pre&gt;Yes you were right, and Alexandrescu it's good

I like the idea of policy

But there are some problems that I can't understand:
It bogus me the fact that I can't select when an handle need or not the 
session - it can't be a "handler policy"? I don't really like pay what I 
don't use

What if a policy need an custom constructor or some settings? If I have 
session that look up on a database or a thread safe hashtable, first I 
can't understand where I will construct session if it need some values 
(like passing an "dbpool" or the reference of an thread safe hashtable)

How you will inject these policy in basic_server?

Thank you

Il giorno mercoledì 22 maggio 2013 03:29:23 UTC+2, Dean Michael Berris ha 
scritto:

&lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-22T07:11:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2222">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2222</link>
    <description>&lt;pre&gt;Before we go any further, look at "policy based designs" -- if you can
pick up the book "Modern C++ Design" by Andrei Alexandrescu that would
be better.

I can't go through each and every point you raise here but:

- The intent of the policy based design is so that anybody can
implement a different policy for things like the dispatcher, the
session manager, the connection manager, among other things.
- The server exposes a single API that depends on APIs from the
underlying policies.
- Once the server has started accepting requests, it manages
connections (via the connection manager), it parses requests, finds
the appropriate session (if necessary, and only if the session manager
supports it), find the appropriate handler (via the dispatcher),
invokes the handler provided the retrieved session (the session can be
empty, or ignored by the handler) and the connection (provided by the
connection manager).

There's no need for having a split between the backend's because each
of these things are policies.

There&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-22T01:29:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2221">
    <title>Re: chunked transfer-encoding</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2221</link>
    <description>&lt;pre&gt;
Please post code to reproduce, what version of the library you're
using, what version of Boost, what compiler and what platform. I
cannot help you with just this information.


&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-22T01:07:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2220">
    <title>chunked transfer-encoding</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2220</link>
    <description>&lt;pre&gt;Does the library already support* *chunked transfer-encoding at client 
side? One of the website I used appears to be sending back the chunked 
transfer-encoding field in the header, but somehow, this library appears to 
be not seeing it, and I verified with a third party tool that can print out 
that field from a same response. Am I missing anything here? or it's just 
the library doesn't handle and ignore that field?

Thanks.

&lt;/pre&gt;</description>
    <dc:creator>shawnhe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-22T00:33:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2219">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2219</link>
    <description>&lt;pre&gt;I was thinking about it, and creating a class deriving from server_base can 
let you to add personalized methods for add a route to the dispatcher

But I continue to be unsure why server_base need to know about session, how 
add a route and about auth

Why server must know how to add a route to the dispatcher? Is it not better 
expose directly the dispatcher and let who designed it decide what must be 
public?

Is not better to inject dispatcher and auth to the server_base constructor? 
Or is already intended to do so?

Session and auth is something that matter at handler level, not server 
level IMHO

Could auth, session and maybe dispatcher spitted in different "project" 
like uri? Such as netlib-auth, netlib-session...

Session could be divided in 2 parts like:
class session_backend: add, get, delete
class session_backend_ram: ...

class session_client(connection, session_backend) : add, get, delete

If so, it makes sense to move the backend in the server context

I'm sorry if you can find this arrogant, &lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-21T17:37:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2218">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2218</link>
    <description>&lt;pre&gt;Ok
Of all this components, witch one will be executed for any request? Only 
the dispatcher? What about session?
When and where other components are supposed to be constructed?

Can you show some pseudo code of a this simple user case?

"For a given path /user/$id get from a db an json encoded result, only for 
authorized used via an database. Get client authorization data from the 
cookie"

From what I can understand it will resolve with this pseudo code:

Create a new class that derive from server_base
Call the personalized constructor of dispatcher and auth, such as
auth = custom_auth(dbpool); 

If I don't derive from server_base, how is it possible to call a non 
default constructor for auth?

personal_server_.register_handler("/user/$id", [](session&amp;amp; s, 
shared_ptr&amp;lt;connection&amp;gt; c) { //Constructor for session called  for any 
request
userid = s["userid"];
password_hash =s["password_hash"];
if(!auth.check(userid, password_hash)) { //how is auth accessible from 
there?
  c-&amp;gt;response()-&amp;gt;send(...);
  return;
&lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-21T16:53:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2217">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2217</link>
    <description>&lt;pre&gt;The dispatcher is a policy and the session manager is also a policy.
They're two different parts of the server infrastructure that are
glued together by the HTTP server -- all the server does is glue
together the different policies relying on interfaces and "contracts",
and all the dispatching happens in the dispatcher (finding the correct
handler given a request) and then provides the appropriate data to the
handler.

The dispatcher implementation can do whatever it wants when finding a
given handler -- it can use regular expressions, it can do it
statically, etc. -- and it can provide a default handler for the 404
case.

There's a lot of leeway with what a dispatcher, session manager, and
connection manager can do in isolation (you can imagine a lot of
different policies mixing and matching together to support many
different use-cases) and the intent is to make each one of these
things pluggable.

Have you looked at what's implemented in the branch yet?

On Tue, May 21, 2013 at 10:12 PM, Nicola Bizzoca
&amp;lt;ni&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-21T12:24:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2216">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2216</link>
    <description>&lt;pre&gt;Yes using template it's better

I was thinking, why not move session and auth outside base_server, maybe 
inside the dispatcher?
IMHO would be better have a "fast path" where server don't do what the 
handler don't need, with a way to declare when you need session, auth, 
cookies and so on

For example on top of server someone could implement a dispatcher similar 
to:

server_.register_handler("/", [](shared_ptr&amp;lt;connection&amp;gt; c) { ... });
server_.register_handler("/test", [](shared_ptr&amp;lt;connection&amp;gt; c, session&amp;amp; s){ ... });
server_.register_handler("/message", [](shared_ptr&amp;lt;connection&amp;gt; c, session&amp;amp; 
s, cookie&amp;amp; c) { ... });

Maybe even
server_.register_handler("/post", {
    get = [](shared_ptr&amp;lt;connection&amp;gt; c) { c-&amp;gt;redirect("/test"); },
     post = [](shared_ptr&amp;lt;connection&amp;gt; c, session&amp;amp; s, cookie&amp;amp; c) { ... } )
}); //Pseudo code, I don't know how it is viable in C++

I don't know if is it possible, having an overloaded register_handler based 
on the functionality that the handler requires

Another question is:
Have yo&lt;/pre&gt;</description>
    <dc:creator>Nicola Bizzoca</dc:creator>
    <dc:date>2013-05-21T12:12:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2215">
    <title>Re: http-server-rewrite branch questions</title>
    <link>http://permalink.gmane.org/gmane.comp.networking.cpp-netlib.devel/2215</link>
    <description>&lt;pre&gt;On Tue, May 21, 2013 at 4:01 AM, Nicola Bizzoca
&amp;lt;nicola.bizzoca-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

Yes.


Well, not really. We're approaching it from a different angle with policies.


We already do with the current implementation (0.9.4) and yes we will.


Yes, and the client soon will -- I think what you're asking though is
whether it will support re-using connections, in which case the answer
will be yes to both.

Perhaps you're interested in helping out and continuing the changes in
the http-server-rewrite branch?

PS. The design doc is here:
https://docs.google.com/document/d/1jUJxs99bcbxAFIWn4Slm8JIMMmrtKc3jwhBz6Da05Lk/edit

&lt;/pre&gt;</description>
    <dc:creator>Dean Michael Berris</dc:creator>
    <dc:date>2013-05-21T04:50:03</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.networking.cpp-netlib.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.networking.cpp-netlib.devel</link>
  </textinput>
</rdf:RDF>
