HttpServerRequestRouter and... WebSockets

[marco.m]

Hey Vinícius,

since we are talking about the request router :-) consider this
scenario:

I want to build a web server that handles *both* HTTP and WebSockets.
For the HTTP part, I am using the request router. It is an elegant way
and I like it. But, I also need websockets. To my understanding, to
handle websockets, I must create my own server inheriting from
Tufao::HttpServer and then overriding upgrade().

So I have a router and a custom server, and I connect the two via
requestReady/handleRequest. It works fine.
By now, I think you are seing where I am going. If the websocket
server needs to handle multiple URLs, it must do it in upgrade(), by
switching around request->url(). But this is exactly what the router
was meant to solve!

Said in another way, I would like, conceptually, to have the router
handling both http:// and ws:// URL schemes. Either the same router,
or two routers.

Any ideas?
marco.m

[Vinícius dos Santos Oliveira]

2013/3/14 marco.m <marco.molte...@gmail.com>

I must create my own server inheriting from
Tufao::HttpServer and then overriding upgrade().

The inheriting thing to handle upgrades was a mistake. I replaced it by std::function in Tufão 1.0-wip.

Any ideas?

The HttpServerRequestRouter handles the pair (HttpServerRequest, HttpServerResponse). The UpgradeHandler handles the pair (HttpServerRequest, QByteArray). They are incompatible.

I should create a second class. I think HttpServerUpgradeRouter is a good name.

I can finish the pending *Router tasks next week (this week is a bit busy for me).

--
Vinícius dos Santos Oliveira
https://plus.google.com/118295250366112843114
http://vinipsmaker.wordpress.com/

Linux user #481186

Majoring in Computer Science (UFAL)

[Vinícius dos Santos Oliveira]

2013/3/14 Vinícius dos Santos Oliveira <vini.i...@gmail.com>

I should create a second class. I think HttpServerUpgradeRouter is a good name.

Version 0.6 released with support for http upgrade routing:

https://github.com/vinipsmaker/tufao/tree/0.6

Take a look at HttpServer::setHttpUpgradeRouter.

I'll update the documentation at http://vinipsmaker.github.com/tufao/ref/0.x/ later this week.

[marco.m]

On Mar 20, 1:35 am, Vinícius dos Santos Oliveira

<vini.ipsma...@gmail.com> wrote:

> Version 0.6 released with support for http upgrade routing:https://github.com/vinipsmaker/tufao/tree/0.6

thanks :-) I should be able to look at it in the following days and
come back with my feedback.

thanks again for your reactivity :-)
marco.m

[Vinícius dos Santos Oliveira]

2013/3/21 marco.m <marco.molte...@gmail.com>

thanks :-) I should be able to look at it in the following days and
come back with my feedback.

Your feedback is appreciated. Let me know if the documentation is alright also.

[marco.m]

I ported my code to use the new HttpUpgradeRouter instead of my home-
brew stuff and it works fine, thanks :-)

And now for the nitpicking :-)
From an API design point of view, the usage is inconsistent with
respect to HttpserverRequestRouter (one uses signals, the other not).
I was wondering if there is a reason. Consider:

================================
Tufao::HttpServer server;
Tufao::HttpServerRequestRouter requestRouter;
Tufao::HttpUpgradeRouter upgradeRouter;

RequestHandler requestHandler;
UpgradeHandler upgradeHandler;

requestRouter.map(..., &requestHandler);
upgradeRouter.map(..., &upgradeHandler);

// Until here, consistent usage, but now...

QObject::connect(&server, SIGNAL(requestReady(...)),
&requestRouter, SLOT(handleRequest(...)));

server.setHttpUpgradeRouter(&upgradeRouter);
================================

to me, either both should use signals, or both should use
setXXXRouter(). Am I missing something?

[Vinícius dos Santos Oliveira]

2013/3/26 marco.m <marco....@laposte.net>

From an API design point of view, the usage is inconsistent with
respect to HttpserverRequestRouter (one uses signals, the other not).

You're right, the API design is inconsistent.

The initial Tufão design was heavily influenied by Node.js. In Node.js, the request event doesn't have a default behaviour, but the upgrade event does it. I translated this design explicitly using signals and protected virtual methods. I think Node.js choose this design to speed up the creation of a complete http server (this pattern also appears in "continue requests"), but it didn't fit well in C++.

[...] to me, either both should use signals, or both should use

setXXXRouter(). Am I missing something?

I shall break the API to fix this design.

Tufão 1.0 will have fixes to these design issues.