Given the cost of add ons I love to see something like the web booster technology supported out of the Domino server box.

One application of this would be a way to gzip certain resources, like javascript libraries or css files. For instance, something like a check box in the properties for a resource, or a way to gzip a whole bunch of things at once from a Designer view. So from then on when the Domino server sends that file to the browser it is automatically sent in compressed form.

Domino doing its own internal algorithm, trying to figure out what to gzip and what not to, is a little scary to me. When that sort of thing goes wrong, it seems there is no way to turn it off. Give developers the option. Doing it within the database seems to me the most flexible way to go because developers do not always have access to the file system on the servers.

There IS a form of gzip support in the Domino server today. We used it on our re-write of the Lotus online forums. You'd have to ask Henry Newberry to get the details but if you store gzipped files appropriately, then rub your belly and pat your head the right way, it works.

gzip is by far the most needed feature. Gzip dramatically reduces bandwidth usage and display speed. We have clients that have purchased expensive hardware and software that does it for domino and the effect is significant. Pages display much faster, even on a LAN, and we are pushing the limits of some user's connections when large views are displayed. If we gzip the domino generated views we see savings of 90% (300k shrinks to 3k), which takes enormous views and makes them very doable without adding navigation complexity.

There is a reason this has been added to all competitive web servers years and years ago.

Does anybody know this link here:

{ Link }

@5 - Yes I tried it on an R7 server and found it to be *hugely* unstable. Must admit to not having tried with R8 but in reality there are very few companies that would allow an undocumented hack to be turned on at the server level!

I suppose it's worth noting on here that ND8.5 will fully support GZip compression (along with a whole lot else). Can't wait for it :-)

Well, looks like 8.5 Beta 1 doesn't support Gzip yet...

{ Link }

Seems that gzip support for static files only is what we can expect. I hope I'm wrong.

From the admin help:

The name of the compressed file is the name of the original file with an additional extension of .gz. For example, the gzip counterpart of c:\notes\data\domino\html\foo.html is c:\notes\data\domino\html\foo.html.gz. (A browser sees this file as { Link }

The original file must be present in the same directory as the gzip file. The original file is served if it is newer than the gzip file or compression is disabled.

The browser or other client must send the request header Accept-Encoding: gzip (the default for most browsers).

The MIME Content-type of the file must match text/* (all subtypes of type text) or application/* (all subtypes of type application).

The server does not support sending a range of bytes for a file that has a gzip counterpart. The server does not send "Accept-Ranges: bytes" in the HTTP header and sends the entire compressed file.

Those borderline criminals at IBM Lotus are doing a great job :) Would love to see GZIP fully supported!

Static resources such as shared Javascript, stylesheets, file resources etc are an easy win since they only change when design is updated. Therefore the .gz file can be generated at compile time, not dynamically (potential performance hit) by HTTP task.

Forms/Page/Views etc, can't see it possible to use gZip here since they're inherently / potentially dynamic.

With 8.5.1 gzip is fully support for static files along with the ability to have them gzipped automatically by the Domino Server.

I would agree with Mark ( @11 ), it wouldn't make sense for supporting dynamic content. The idea is the gzipped file is cached on the server to improve performance. It would be nice if the automatic creation would include file resouces and not just File System based files.

The server creates the gzip in the same folder when it either doesn't exist or the gzip file is older then the original.

Looks like we've moved in the right direction with 8.5.1 - fantastic for scalability.

I think there's a stumbling block with resources inside NSFs because each time any note is modified (ie doc updates etc), the database modified stamp changes which I believe triggers a cache expiry. This is my impression anyway, after doing some sniffing around.

8.5.1 Can also GZip *any* Domino output, including stuff sourced from within NSF (forms, views, etc.)

This idea should be marked as "resolved".