Weblog

3 November 2015, 18:00

Here are my plans for the next major release of the Hiawatha webserver. All are configuration related.

  • The biggest change is the different way of handling Directory{} sections. Directory settings will be linked to virtual hosts, just like UrlToolkits and FastCGI servers. Paths will be relative to the DocumentRoot of the virtual host.
    VirtualHost {
      ...
      UseDirectory = mydir[, ...]
    }
    
    Directory {
      DirectoryID = mydir
      Path = /files
      ...
    }
    
  • Add support for on-the-fly GZip content encoding. Will make the UseGZfile option obsolete.
  • Make 'yes' the default for IgnoreDotHiawatha.
  • Remove the VolatileObject option. This can also be done via a CGI application.
  • Remove the UserWebsites option. Nobody uses it and it can be simulated via the Alias option.

Please, let me know what you think of it.

kfft
3 November 2015, 21:04
They all go in the good direction of simplification and clarification of the configuration. I am 100% supportive.
Richard
3 November 2015, 21:11
Good stuff! Thanks a lot for streamlining the configuration! I <3 Hiawatha!
Gilad
3 November 2015, 21:24
Being a fan and user for years I agree - it's a good call in making Hiawatha streamlined with other web server syntax thus making it easier for newbies to migrate.

That said - if you're indeed going to re-do the config file I suggest writing an automatic migration script to allow current users to easily update their current config files. That will save you a lot of support work and hassle.

Keep on the good work dear Hugo!
bkh
4 November 2015, 03:04
Linking Directory settings to virtual hosts is a great idea and will lead to welcome simplification. Thanks for the great work!
Chandra
4 November 2015, 03:27
Can you reconsider adding GZIP. I think Bruce idea is good: https://www.hiawatha-webserver.org/forum/topic/1464

Thanks.
Bier
4 November 2015, 08:46
Thanks for the changes at Directory handling!
Bier
4 November 2015, 09:15
PS: The gzip caching noted by Chandra seems to be a good idea for me
Richard
4 November 2015, 10:11
> PS: The gzip caching noted by Chandra seems to be a good idea for me

+1 from me!
Klemens
4 November 2015, 13:51
Linking the Directory block to the VirtualHost sounds like a good idea to me. And I never used VolatileObject or UserWebsites, so go ahead an remove them. ;-)
Hugo Leisink
5 November 2015, 18:42
GZip support has been implemented. Hiawatha uses the work directory to store gzipped versions of requested file. So, GZipping is not done over and over again for every file.
Chandra
6 November 2015, 04:13
@Hugo, oh didn't realized that. Maybe you should update the FAQs:https://www.hiawatha-webserver.org/faq to prevent more misunderstanding.

Thanks!
Chandra
6 November 2015, 04:40
Wait, I misunderstood that as GZIP already implemented before 10. Haha. Thanks Hugo for adding GZIP!

Source: https://mobile.twitter.com/hiawatha_ws/status/662332308054286336
Kalileo
7 November 2015, 07:10
The changes make sense.
Some time ago you thought about moving the config to a database, but you didn't. I fully agree, polling a database causes load at the wrong place, where the server core needs be as small and minimal, as possible, to run as fast as possible.
I also like the way you added Gzip support, zip once only.
Thanks for Hiawatha!
Hugo Leisink
7 November 2015, 07:49
It was only intended as an optional move, in case you wanted to maintain many webservers via a single interface. The reason I didn't go through with that plan is because other external solutions already offer that.
Rapha
9 November 2015, 15:53
Take a look to this post. https://www.hiawatha-webserver.org/forum/topic/1997/
I can understand what this user means.
The hackers are searching for security issues with google. I would protect some security-related links by IP-Filter, so denied user see an error page (not found), which google will not list in search results
This would be very nice security feature,
Think about this Hugo.
Hugo Leisink
9 November 2015, 17:48
Clients can be blocked via the AccessList option. Use the ErrorXSLT option to define your own error message.
Rapha
9 November 2015, 17:56
Oh, if this works the way I imagine it, then everything is wonderful. I will try it.
Benjamin
10 November 2015, 18:35
What about letsencrypt [letsencrypt.org] plugin for Hiawatha?
There are currently plugins for Apache [github.com] and Nginx [github.com].
Can you ensure that there is also a plugin for Hiawatha?
It would be great
Hugo Leisink
10 November 2015, 22:49
No, I cannot ensure that. But it's not required. https://robotanarchy.space/lets-encrypt-hiawatha/
Chandra
16 November 2015, 23:39
Hi Hugo, is there something like Nginx's FastCGI caching in Hiawatha to cache full content of dynamic content (e.g WordPress)? So it can be served directly from Hiawatha if the cache exists.

If it's already available can you point me to the howto? I tried to search for it and only found: https://dotbalm.org/http-caching-in-hiawatha/

If not, I'm requesting it. Maybe not 10 if it's not possible.

Thanks for the great software! I'm really excited to use Hiawatha 10 stable.
Hugo Leisink
17 November 2015, 23:01
Chandra, it is already supported. Look in the manual page for the section named 'CGI OUTPUT CACHE'.
Marius Dinu
25 November 2015, 15:10
Does this change mean that I can't add directories outside DocumentRoot? This is not good!
I have DocRoot in D:\HTTP and virtual subdirectories pointing to drive E: and F:. On my router I have DocRoot in /HTTP and shared directories in /mnt/usb1/
Your proposed change will break a lot of things.
Smö
16 December 2015, 23:30
I use UserWebsites