Forum

Hello!

I've rented space at some server which provides VPS-like features in a sense that one can build one's own stuff (e.g. webserver) and run it on some of the available local ports behind nginx at the front-end which serves as reverse proxy.

I like this hosting 'cause it provides features like full VPS witho0ut the headache of doing admin work for the whole VPS like mail, database servers etc.

Control panel is meant for easy Django-deployment so that each Django app can use customized lighty server.

For 'normal' PHP apps, nginx at the front-end dispatches requests to Apache2.

I'd like to use my own webserver behind reverse-proxy to serve all my web sites using Tiki CMS with php-fpm.

At the moment I've problem with reverse proxy giving 504 timeout, but I'm sure we can solve it either by installing via Apache or by installing Tiki by hand.

Considering that I'm not a big fan of lighty (haven't tried 2.0), but had leaks when used for FastCGI, I was quite happy with Cherokee in the past, but its development stalled a bit and therefore I was investigating about possible alternatives, so Wikipedia page has led me to 'discover' Hiawatha. :-)

My production server uses Debian (stable) and, as I wrote above, I could use Hiawatha as my custom webserver behind nginx running as reverse-proxy to serve my Tiki CMS PHP sites (I gave up on Django & uwsgi), so wonder how good can Hiawatha be in such environment when it's not front-end server, iow. does it influence its security features somehow?

Another thing is that .htaccess is quite a big file for Tiki CMS and I wonder how difficult would be to convert rewrite rules to Hiawatha?

I'm not overly familiar with htaccess, but know there is online htaccess --> Nginx converter.

Another possible advantage of Hiawatha (over Nginx) could be the fact that there is problem with Tiki and its rewriting mechanism due to abusing Apache a bit - here is the link (http://www.stevestreeting.com/2012/05/09/apache-to-nginx-php-fpm-part-1/) with short explanation:
"Although converting rewrite rules was generally quite easy, I did have one major issue with Nginx that was specific to Tiki. Its wiki encodes space characters in page names as ‘+’, and uses this as links, which is fine when used as a query string, e.g. http://something.org/tiki/tiki-index.php?page=Some+Page. However, when you tell it to generate short page links, Tiki simply drops the ‘tiki-index.php?page=’ part when outputting links and expects the rewrite rule to put it back later, so your URLs become something like http://something.org/tiki/Some+Page. On Apache (and lighttpd), rewriting this back to http://something.org/tiki/tiki-index.php?page=Some+Page works fine, but on Nginx it doesn’t work. The reason is that while Apache just takes the URI as-is when it’s rewriting it, Nginx decodes the URI, rewrites it, then re-encodes it when passing it on. It turns out that according to RFC 3986 using ‘+’ outside of the scheme or query string in a URI as the Tiki shortlinks do is invalid, so Nginx actually re-encodes the ‘+’ as %2B when it passes the result back, breaking the page name."

How does Hiawatha behave in such situation?

I can use 500MB altogether for my web sites (aplications) and I built my own version of PHP(-FPM) and wonder how is Hiawatha memory-wise (read a study about performance)?

Excuse me for a bit longish post, but let me end it with a simple question: do you consider that Hiawatha webserver is a good choice for me considering my use case (running few Tiki CMS sites) and my server's environment (500MB and server behind nginx reverse-proxy)=


Sincerely,
Gour


Hiawatha version:
Operating System:

That's one big ugly and definitely nasty URL rewrite rule. That alone would keep me away from TikiCMS.

I've taken a quick look at the rules and I think it's very well possible to convert them to Hiawatha UrlToolkit rules. It's probably nothing more than changing Apache's "RewriteRule <pattern> <newurl>" style to Hiawatha's "Match <pattern> Rewrite <newurl>". Read the UrlToolkit HOWTO page for the availble options.

My advice: submit a bugreport for this big URL rewrite rule set. Because that's what it is: a bug, bad programming. The only thing a rewrite rule should contain is rewriting requests for non-existing files to a single index.php, nothing more. The index.php should handle the routing.

> That's one big ugly and definitely nasty URL rewrite rule. That alone would keep me away from TikiCMS.

Well, I tried so many CMS-es, both in PHP and Django arena (using WP/Concrete5) and recently played with TYPO3...and Tiki CMS looks quite nice and capable otherwise.

> I've taken a quick look at the rules and I think it's very well possible to convert them to Hiawatha UrlToolkit rules. It's probably nothing more than changing Apache's "RewriteRule <pattern> <newurl>" style to Hiawatha's "Match <pattern> Rewrite <newurl>". Read the UrlToolkit HOWTO page for the availble options.

OK. Thank you,

> My advice: submit a bugreport for this big URL rewrite rule set. Because that's what it is: a bug, bad programming. The only thing a rewrite rule should contain is rewriting requests for non-existing files to a single index.php, nothing more. The index.php should handle the routing.

I'll do it.

What do you think about other aspects of using Hiawatha in my server environment, like running behind nginx as reverse-proxy?

If you can fix TikiCMS's url-rewriting hell, Hiawatha won't be the problem. Hiawatha also has reverse-proxy functionality, so why use nginx?

> If you can fix TikiCMS's url-rewriting hell, Hiawatha won't be the problem.

I hope it will be fixed eventually.

> Hiawatha also has reverse-proxy functionality, so why use nginx?

Simple reason - I do not own the root on the server being just one shared user...and unless I find some cheap VPS hosting, there is no other way.

You may visit http://lowendbox.com
lots of offers for really cheap vpses.

Thanks. I did it yesterday, but just wonder whether to go into it 'cause I was not managing my own mail server for quite some time...last time I did with qmail. :-)

Iow, wonder how much admin work it involves if it's unmanaged VPS? The managed one's are probably too expensive for my budget.