Domain: hiawatha-webserver.org
Stories and comments across the archive that link to hiawatha-webserver.org.
Comments · 15
-
Hiawatha webserver and Let's Encrypt
The latest release of the Hiawatha webserver has its own Let's Encrypt script included. Seems to work ok. Anybody tried Hiawatha yet? How good is it?
-
Re:Simple question
I don't agree with point 3. In my open source project, I changed from OpenSSL to mbed TLS in a few days.
-
Hiawatha
So glad that I'm using a webserver that does NOT use this abomination called OpenSSL and was writting with security in mind. Drown, Heartbleed, Slowloris, etc, never caused me any trouble.
-
Re:PHP
Then you didn't even look at those websites. There are enough attack vectors. There are login pages (add
/cms to the URL), weblogs with comments, a public forum and many other forms (login with demo:demo). -
Re:PHP
Then you didn't even look at those websites. There are enough attack vectors. There are login pages (add
/cms to the URL), weblogs with comments, a public forum and many other forms (login with demo:demo). -
Webserver with ability to block SQL injection
The Hiawatha webserver can block SQL injection attacks. I like to hear what you think of it.
-
Hiawatha webserver
Or the quite unknown Hiawatha webserver. A very good alternative to the well known Apache webserver and completely written by one person.
-
No more!
Every software developer, please stop using OpenSSL. It was crap then, it is crap now and it will be crap tomorrow. And LibreSSL is not the solution. You can't turn crap into something nice. You want a decent SSL library, try mbed TLS. Unlike OpenSSL, this library has good documentation (example programs included), has a logical and sane API (no ugly callback shit) and its code is clean and secure.
I switched from OpenSSL to mbed TLS (named PolarSSL back then) in my open source project some time ago. I should have done it more early! The migration was easy and only cost me a few days. So, stop punishing yourself and give mbed TLS a try. You won't regret it!!
Disclaimer:
No, I'm in no way connected to mbed TLS. Just a happy mbed TLS user who doesn't understand why people keep on torturing themselves and their users. -
New HTTP daemon
I understand they replaced nginx with something different. But why a half-finished webserver that doesn't even support things like URL rewriting. For those who seek a secure webserver, but with features to properly support the modern website/framework/CMS, try the Hiawatha webserver.
-
Not really happy
As the author of an open source webserver, I must say that I'm not really happy with HTTP/2. It adds a lot of extra complexity to the server side of the protocol. And all sorts of ugly and nasty things in HTTP/1 (too much work to go into that right now) have not been fixed.
What I have experienced is that SPDY (and therefor also HTTP/2) will only offer more speed if you are Google or are like Google. Multiplexing doesn't offer that much speed increase as some people would like you to believe. Often, the content of a website is located on multiple systems (pictures, advertisements, etc), which still requires that the browser uses more than one connection, even with HTTP/2. Also, HTTP/1 already allows a browser to send multiple requests without waiting for the response of the previous request. This is called request pipelining, but is turned off by default in most browsers. What I also often see is that a browser makes a first request (often for a CGI script) and the following requests (for the images, JS, CSS, etc) are never made due to browser caching. So, to me HTTP/2 adds a lot of complexity with almost no benefits in return.
Then why do we have HTTP/2? Well, because it's good for Google. They have all the content for their websites on their own servers. Because IETF failed to come up with a HTTP/2 proposal, a commercial company (Google in this case) used that to take control. HTTP/2 is in fact a protocol by Google, for Google.
In my experience, you are far better off with smart caching. With that, you will be able to get far better speed-increase results than HTTP/2 will ever offer. Specially if you use a framework that communicates directly with the webserver about this (like I did with my PHP framework). You will be able to get hundreds to thousands requests per second for a CGI script instead of a few tens of requests. This is a speed increase that HTTP/2 will never offer.
I think this is a failed change to do it right. HTTP is just like SMTP and FTP one of those ancient protocols. In the last 20 years, a lot has changed. HTTP/1 worked fine for those years. But for where the internet is headed, we need something new. Something completely new and not a HTTP/1 patch.
-
Re:Obligatory reminder that an alternative exists
Why start with something bad to make something good. If you want a good SSL library, try PolarSSL. It's a quite unknown, but great library. Unlike OpenSSL, this one has good documentation. The Hiawatha webserver uses it and it easily gives me an A+ score at SSL labs.
-
Not vulnerable
It seems that the Hiawatha webserver is not vulnerable for this exploit, because it doesn't URL decode environment variables. Wise decision (CGI's seem to work fine without it) or just luck? Is there a standard which says that CGI environment variables should be URL decoded?
-
SPDY doesn't solve the real issues
The biggest problem with SPDY is that it's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit from it. In my free time, I'm writing an open source webserver and by doing so, I've encountered several bad things in the HTTP and CGI standard. Things can be made really more easy and thus faster if we, for example, agree to let go of this rediculous pathinfo, agree that requests within the same connection are always for the same host and make the CGI headers work better with HTTP.
You want things to be faster? Start by making things more simple. Just take a look at all the modules for Apache. The amount of crap many web developers want to put into their website can't be fixed by a new HTTP protocol.
We don't need HTTP/2.0. HTTP/1.3 with some things removed, fixed or at least have some vague things be specified more clearly, would be more than enough for 95% of all the websites.
-
Re:Real question
Not GnuTLS, but PolarSSL. Reason for moving away from OpenSSL is because of it's horrible documentation. Or, better said, the lack of any documentation. Tried to implement SNI support in my open source web server (Hiawatha http://www.hiawatha-webserver....), but there was no proper documentation or example code available. With PolarSSL, it was done within a day. All other SSL features were implemented in a more cleaner way. No ugly callback stuff. Even with the OpenSSL 1.0.0 release some time ago their documentation was still incomplete. I seriously don't now how to take a piece of software (specially libraries) serious with proper and complete documentation. I believe proper documentation and support is even more essential to software than code quality.
-
Banshee on Hiawatha
Use the Banshee PHP framework on the Hiawatha webserver. Both have a strong focus on security and offer good speed. Use stuff like Drupal, Joomla and Concrete5 if you want your website to be extremely slow. Use Wordpress if you want guarantee to be hacked.