Forum

Hello Hugo,

We would like to clarify something about RequiredBinding. I think right now this directive is a bit confusing.

We discussed it earlier, but I still want to ask for this.

You mentioned that right now Hiawatha listens on All bindings (let's say Non-SSL and SSL).

So if you specify RequiredBinding on a vhost (let's say SSL), then according to you Hiawatha will stop listening on Non-SSL binding for that virtual host.

However, this is a bit confusing. What is the point of limiting bindings, unless you want to specify 2 Vhosts:

VirtualHost {
    Hostname = domain.com
    WebsiteRoot = /var/www/hiawatha
    ReverseProxy .* https://67.23.169.105:443/ 60
    SSLcertFile = /etc/hiawatha/ssl/domain.pem
    RequiredBinding = SSL
}

VirtualHost {
    Hostname = domain.com
    WebsiteRoot = /var/www/hiawatha
    ReverseProxy .* http://67.23.169.105:80/ 60
    SSLcertFile = /etc/hiawatha/ssl/cloudlayar.pem
    RequiredBinding = NON-SSL
}

I think it would seem logical to use the RequiredBinding directive in order to separate traffic between SSL and non-SSL.

Otherwise, I don't see much use of the RequiredBinding directive...


Seems we are not the only ones having this issue: https://www.hiawatha-webserver.org/forum/topic/1502

It's use case is indeed limited, but image a webserver with a LAN interface and a WAN / DMZ interface. Although an intranet website will have a hostname that only resolves within the intranet, it will still be possible to visit such a website via the internet via a /etc/hosts trick. Via the RequiredBinding option, you can limit the visibility for websites for specific interfaces.

Hello Hugo,

I see your point, but such example seems extremely rare. Maybe I`m wrong, but out of tens of thousands of clients we have seen noone with such setup.

By contrast, if you would allow hiawatha to have duplicate hostnames, but with different bindings, it would be a quick fix for the ssl/non-ssl traffic issue.

What happens right now is that if you specify vhost reverse proxy to listen on all interfaces but direct traffic to port 443, then all traffic goes to port 443,

And visitors are unable to browse the insecure version of the website.

Regards
Andrew

Yes, it is extremely rare, but I've used it in my student time. A public website for the student hous I lived in and one internal to splits costs for shopping etc. And this feature was originally requested by someone else. Best for you is to simply ignore / forget this option. I will think of a solution for the SSL / non-SSL case.

Ok, what I have implemented for v9.10 is that you can specify multiple reverse proxies for one virtual host and Hiawatha will prefer the reverse proxy with a scheme matching the one of the client connection. That will make the configuration as mentioned in the first post of this topic work. Ok for you?

Hello Hugo,

Thank you for your reply.

I think this will be the best. This would make hiawatha comply with industry standards I think

Regards
Andrew