Forum

[Request] Disable/enable .hiawatha and declare ReverseProxy inside section

Mustafa Ramadhan
30 October 2014, 01:49

Hiawatha version: 9.8
Operating System: CentOS 6.6

1. Need new parameter like 'EnableDirLevelConfig = yes/no' for enable/disable .hiawatha

The reason is .hiawatha is good feature but dangerous for shared-hosting. If client create .hiawatha with wrong content and then hiawatha service fail to restart.

Beside this feature, better add code in hiawatha to bypass .hiawatha if found wrong/error code. Let say, like 'try-catch' login in php. With this logic, wrong code inside .hiawatha only effect to website with wrong code only. This is like .htaccess do in apache

2. Need new section like 'ReverseProxy {}' and call it as 'useReverseProxy'

Hiawatha have special section for 'FastCGIserver' (declare as 'FastCGIserver {}') and call it as 'UseFastCGI' inside 'VirtualHost {}' or 'UrlToolkit {}'.

If Hiawatha also have 'ReverseProxy {}' section, it's alternative ('jump from handicap') where Hiawatha doesn't have '2 level include' (read https://www.hiawatha-webserver.org/forum/topic/1710)
Hugo Leisink
30 October 2014, 07:45
1. Hiawatha doesn't look at .hiawatha files upon startup, so errors in one of those files can't make Hiawatha fail at startup. And Hiawatha already has the IgnoreDotHiawatha option.

2. Not sure about this one. A reverse proxy takes only one configuration line, so placing it in a ReverseProxy{} section is a bit of an overkill. If you have multiple websites that need forwarding to a reverse proxy, why not use all their hostnames in one virtual host configuration (comma separated Hostname setting).
Mustafa Ramadhan
30 October 2014, 12:50
1. Thanks for this info

2. Can you give me more explain for 'If you have multiple websites that need forwarding to a reverse proxy, why not use all their hostnames in one virtual host configuration (comma separated Hostname setting).'?

It's not related to 'ReverseProxy' only. Imagine, if we have 1000+ website and then switch from hiawatha to hiawatha-proxy and vice-versa must be re-create their domain configs one-by-one.

Example for nginx. Let say, I have 2 types of include file (proxy.inc and fastcgi.inc). In virtualhost, appear 'include switch.inc'. If I want running under proxy, just copy proxy.inc to switch.inc. Otherwise, copy fastcgi.inc to switch.inc.
Mustafa Ramadhan
31 October 2014, 04:09
Or feature something like:
UrlToolkit {
ToolkitID = proxy
IgnoreDotHiawatha = yes
ReverseProxy !\.(pl|cgi|py|rb|shmtl) http://127.0.0.1:30080/ 90 keep-alive
}
Hugo Leisink
31 October 2014, 11:27
The IgnoreDotHiawatha does not belong in the UrlToolkit.

About the include and it's level-limit, I have no intention of changing it. Mainly because I had no complains about it before and I want to avoid users building complex include constructions and ending up at this forum asking be why it doesn't work. Specially when including files form another directory (what do I do with the current working directory) and moving configuration directories from one place to another. It's asking for trouble.

How about some sort of #define / #ifdef #endif construction? Could that be an option for you?
Mustafa Ramadhan
31 October 2014, 13:42
I mean have an option like:
UrlToolkit {
ToolkitID = proxy
ReverseProxy !\.(pl|cgi|py|rb|shmtl) http://127.0.0.1:30080/ 90 keep-alive
}

where ReverseProxy able to declare inside UrlToolkit (no need 'ReverseProxy {}').

With this options, '2 level include' become unnecessary.
Hugo Leisink
31 October 2014, 20:47
I still don't understand what you try to achieve. And why would you wanna switch from webserver to proxy and then back to webserver?
This topic has been closed.