Forum

There might be a compelling reason to support a minimal reverse proxying feature.
Typical situation is that you have one webserver (hiawatha) hosting say one hundred sites on the same IP-address.
Everything works fine, then one of the sites uses a feature which cannot be provided by hiawatha directly, it needs some kind of application server for that. The application server does not have an fcgi or cgi interface, but it does offer an HTTP interface.

Without using up another IP-address, one basically has two options:
a. Put a dedicated reverse proxy (e.g. nginx) in front, and let that proxy proxy 99 websites to hiawatha, and one website to the dedicated application server (which does sound kind of messy, because for all 99 sites, I increase the overhead and complexity (needlessly)).
b. Or, have hiawatha proxy the requests for that webserver to the application server, just like with fcgi, except in this case use http as the connecting protocol (which should be easy enough, since I'd imagine it would be easier to implement than an (f)fcgi connection).

In my oponion, if a webapplication does not offer a FastCGI or CGI interface, it's a badly designed application. If a webapplication has a HTTP interface and wants to act like a webserver, it should do so, but I'm not going to change Hiawatha in order to support badly written applications.

Second, even if I did agree that proxy functionality would be good for Hiawatha, it's already clear to me that the world doesn't need another webserver. So, I'm not going to put a lot of time in something that nobody uses. At the moment, I'm building Hiawatha for me and some friends and share it with the rest of the world "as it is". I gave up the idea that one day Hiawatha might have a significant market share a long time ago.

Popularity and functionality sometimes are a chicken and egg problem. Any objections when I add the functionality?

I have no objections. But I don't guarantee that I will apply your proxy patch to the official Hiawatha code. Because I really believe that a webserver should be a webserver and should not be polluted with all sorts of other functionality.

So, it's very likely that the best thing I will offer you is that I will place a link to your proxy-patch on this website.

> a webserver and should not be polluted with all sorts of other functionality

Minor nit: if you have the policy quoted above, then why did you add code that creates directories and chowns/chmods files? Because especially those sorts of things fall in that very same category.

With regard to a link to my patch(es); what would be more than sufficient is if you would provide a link to my hiawatha git repository; the link is fixed, it will always be up-to-date, and it will track the version I use in production. No need to address or promote individual patches.