Forum

Hallo,

I read the forum and man-page. I think I understand the way Hiawatha does the GZip-thing but I dont like it.

It is too much work for dynamic webpages to create a gz-file for each file. I can not explain this to the users of my servers that they have to create a gz-file for optimal performance.

I wish that you can choose which way of encoding you want (on the fly or not).

Also a plugin-api would be great to have others implement these features.

Thanks for realizing it, Hugo.

Hiawatha version:
Operating System:

Hiawatha does not support on the fly gzipping. Making on-the-fly gzip support will make Hiawatha slower. Not only because of the gzipping process itself, but also because Hiawatha must buffer the complete output for optimal gzip compression.

A average website consists of text, the HTML which is mostly very small in size, and images, mostly JPEGs which can't be compressed. So, on the fly gzipping is a little overrated if you ask me. Forget on-the-fly gzip. Use 'static' gzip for large file which can be compressed.

Hi Hugo,

Well, experience makes me not agree with you. http://paulbuchheit.blogspot.com/2009/04/make-your-site-faster-and-cheaper-to.html

...and btw ngnix also offers both ways of GZip encoding.

I'll take a look at it for 6.19. No promisses yet.

Great as this is the only feature I am missing in Hiawatha currently for our needs. We are evaluating nginx, lighttpd and Hiawatha currently.

Thanks Hugo.

I vote for it too :-)

Well, you can use nginx as reverse proxy + static content serving. It does a great job while Hiawatha can serve the dynamic generated content from the backend. I am currently researching this solution for various reasons.

Hm, adding another instance...why? Then I could use nginx for everything.

As long as Hiawatha doesnt support the On-The-Fly GZip-Feature I will stick with nginx.

nginx has a crappy URL rewrite support while Hiawatha has a great UrlTookit. Hiawatha has great security features that are bundled with the software. Here's a couple of reasons.

Maybe my first sentence sound wrong, thus here's an errata: nginx's URL rewrite support doesn't produce all the time Apache-compliant output. You may want to replace Apache with something else (otherwise you wouldn't be on hiawatha-webserver.org), but you can't ignore the fact that there are a lot of applications with mod_rewrite oriented design. Apache is still the most popular web server. Until the opposite is proven, Hiawatha still has the best rewrite engine which isn't a mod_rewrite clone.

Now from the subjective point of view, the nginx FastCGI configuration just wants to make me hate that feature. Seriously, event Apache + mod_fastcgi is more human than that. Useless complexity adds security in deployment issues. On the other hand, Hiawatha is easy to configure for this specific reason. If you don't get the security in deployment principle, I would recommend you to research this.

PS: LiteSpeed Web Server would be my weapon of choice if the price tag wouldn't be that high. That's not the point though. The whole webserver is Apache compliant for an obvious good reason.

Why would you need Apache compatibility? We kicked Apache from all our servers around 2001. Currently we are running a few lighttpd instances, a few nginx and are thinking to move everything to one appliance: Hiawatha.

But currently there are a few features missing which are essential to us. I never had problems with lighty's or nginx' mod_rewrite.

I have no experience with LiteSpeed, sorry.

If you write all your applications from scratch, then there's no issue. Also if you use your own in-house framework or something like this, you would not have any issues. There are some 'if's which in the real world appear, while into an ideal world they won't appear. You may be one of those happy admins around the web. I still have to deal with a lot of legacy code. I would remove that junk from the production if I could, but unfortunately that's not up to me. So if someone is in my particular situation, that someone might consider to see things more than in black and white. A proxy may seem more than acceptable this way.

Implementing GZip requires a little more work then expected. It won't be available in 6.19, because I don't want to wait that long with the already implemented feature requests. I'll see what I can do for 6.20.

In the meantime, you could use PHP's output buffer feature to capture all the output and GZip them in PHP:

ob_start();

<your code>

$output = ob_get_contents();
ob_end_clean();

$go_gzip = false;
if (($encodings = $_SERVER["HTTP_ACCEPT_ENCODING"]) !== null) {
  if (strpos($encodings, "gzip") !== false) {
    $do_gzip = true;
  }
}

if ($do_gzip) {
  header("Content-Encoding: gzip");
  print gzencode($output, 6);
} else {
  print $output;
}

It appeared to be even much easier in PHP. Just use these settings in php.ini and you're done.

zlib.output_compression = On
zlib.output_compression_level = 6

Any update here? Or is this feature not under active development anymore?

I've take a look at it. On the fly GZip requires buffering of the entire CGI output. Keeping the buffer in memory is not a option, because busy websites with large content will cause memory problems. Buffering on disk makes it slow, which is not what we want.

Most of the Hiawatha users use PHP (see this poll). Since PHP has GZip support (see my previous post in this topic), I've decided not to implement on the fly GZipping in Hiawatha.

Ok, thanks.