missing URL rewriting?

9 views
Skip to first unread message

marco.m

unread,
Mar 12, 2013, 6:18:58 AM3/12/13
to Tufão
Hi,

I am playing around with Tufao (I contributed peerAddress() and
peerPort() to WebSockets). I am quite liking it :-)

Now I am experimenting with the request router. I understand the map()
method, and the fact that a few standard handlers already exist, such
as HttpFileServer.

I think what is missing is a URL rewrite method. Classic example is
mapping "/" to ''index.html". In my understanding, the only way to do
that in Tufao is writing a custom handler, like is done in examples/
sessionusage/roothandler.cpp. I find it cumbersome to write a class
just to map "/" to "index.html" :-)

I propose to add a method, rewrite(), to the request router:

rewrite(const QRegExp& path, const char* to)

(or maybe with QArray arguments for consistency). The client code
should call it _before_ any map() calls and in any case in the
internal logic, all the rewrites should happen before entering the map
rules.

Example:

Tufao::HttpServerRequestRouter router;
Tufao::HttpFileServer fileServer("public");

router.rewrite(QRegExp("^/$"), "/index.html");
router.map(QRegExp(""), &fileServer);
router.map(QRegExp(""), &handle404);

A request for "http://example.com/" would get a reply with the
contents of public/index.html

What do you think?
marco.m

Vinícius dos Santos Oliveira

unread,
Mar 12, 2013, 11:32:02 AM3/12/13
to Tufão
2013/3/12 marco.m <marco.molte...@gmail.com>
What do you think?

It's a good proposal, but I need to see how this is done in other tools like Node.js, Django and Apache/PHP before implement it in Tufão.

I'd need to add HttpServerRequest::setUrl to allow this kind of abstraction or use the friend keyword and restrict the use of this technique to Tufão itself.

I could also change only the router (tuning the routing rules), but if I do that, the HttpFileServer won't work as expected.

The implementation won't be a problem, but I need to think about the interface that will be exported to the user.


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

Linux user #481186

Majoring in Computer Science (UFAL)

marco.m

unread,
Mar 13, 2013, 4:18:58 AM3/13/13
to Tufão
On Mar 12, 4:32 pm, Vinícius dos Santos Oliveira
<vini.ipsma...@gmail.com> wrote:

[..]

> The implementation won't be a problem, but I need to think about the
> interface that will be exported to the user.

It's a pleasure to see you are trying to keep Tufão cohesive :-)

Please share your design ideas when you are ready.

I also don't understand why changing only the router would break the
HttpFileServer, but I haven't looked closely at the code...

marco.m

Vinícius dos Santos Oliveira

unread,
Mar 13, 2013, 11:58:54 AM3/13/13
to Tufão
2013/3/13 marco.m <marco.molte...@gmail.com>
Please share your design ideas when you are ready.

I was thinking about this:
http://bayimg.com/oAkNOAAEI (source files attached)

...but I won't change anything before see how this is implemented in other frameworks (at least in Node.js and Django).

What do you think about this design?

I also don't understand why changing only the router would break the
HttpFileServer, but I haven't looked closely at the code...

It's my fault. I didn't comunicated the idea very well.

What I wanted to mean in the previous email was to add the rewrite rule on the HttpServerRequestRouter without actually change the url. This is how HttpFileServer could misbehave.
url-rewriter.dia

marco.m

unread,
Mar 14, 2013, 5:57:38 AM3/14/13
to Tufão
On Mar 13, 4:58 pm, Vinícius dos Santos Oliveira
<vini.ipsma...@gmail.com> wrote:
> 2013/3/13 marco.m <marco.molteni.en.voy...@gmail.com>

[..]

> I was thinking about this:http://bayimg.com/oAkNOAAEI(source files attached)
> What do you think about this design?

Ahhh, now I understand. Something like:

bool UrlRewriterHandler::handleRequest(HttpServerRequest *request,
HttpServerResponse *response, const QStringList &args)
{
request.setUrl(this->_newUrl);
false;
}

By returning false, the router would keep calling the other registered
handlers, but with a rewritten URL...

and the client code would be:

Tufao::HttpServerRequestRouter router;
Tufao::HttpFileServer fileServer("public");

router.map(QRegExp("^/$"), UrlRewiterHandler("/index.html"));
router.map(QRegExp(""), &fileServer);
router.map(QRegExp(""), &handle404);

Looks like it would work, as long as you are sure that changing the
URL in the HttpServerRequest object at mid-life (not at construction)
will not break any assumptions made by all the surrounding code that
uses it... :-)

> > I also don't understand why changing only the router would break the
> > HttpFileServer, but I haven't looked closely at the code...
>
> It's my fault. I didn't comunicated the idea very well.
>
> What I wanted to mean in the previous email was to add the rewrite rule on
> the HttpServerRequestRouter without actually change the url. This is how
> HttpFileServer could misbehave.

yes, now I understand.

Thanks again. Your proposal would solve my requirement :-)
marco.m

Vinícius dos Santos Oliveira

unread,
Mar 19, 2013, 8:32:39 PM3/19/13
to Tufão
2013/3/14 marco.m <marco.molte...@gmail.com>

Thanks again. Your proposal would solve my requirement :-)

Version 0.6 released with support for url rewriting:

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

marco.m

unread,
Mar 26, 2013, 9:36:54 AM3/26/13
to Tufão
On Mar 20, 1:32 am, Vinícius dos Santos Oliveira
<vini.ipsma...@gmail.com> wrote:

> Version 0.6 released with support for url rewriting:https://github.com/vinipsmaker/tufao/tree/0.6

I ported my code to use UrlRewriterHandler and got rid of a custom
root handler class. Works fine!

thanks :-)
marco
Reply all
Reply to author
Forward
0 new messages