[hunchentoot-devel] gzip-encoding

[Mac Chan]

On 5/26/07, Edi Weitz <edi at agharta.de> wrote:
> I suppose gzip itself will also take some time, won't it?  Why do you
> think flexi-streams is the culprit in this case?

Because it was convenient to blame flexi-steams ;-) (re: the upload
performance thread)

> I think static files aren't something we should be
> particularly concerned with.  If you have lots of static files and
> Hunchentoot can't serve them fast enough for your purposes, let Apache
> serve them, or put them behind mod_lisp and use mod_gzip.  Besides,
> clients will cache Javascript files, so they'll have to read your big
> Ajax library only once.

I wasn't too concerned about scalability. Like you said, if it is a
public facing high-traffic website, putting hunchentoot behind
mod-lisp would be a safer bet.

However, even in intranet application, downloading 790k verse 220k is
a huge difference in user experience.

And not to mention that you don't have to deal with apache setup and
configuration.

Imagine hacking httpd.conf and installing mods verse writing your own
mod-alias mod-rewrite in lisp, changing the rules in runtime without
restarting the web server. Which one is more fun? ;)

> >         (accept-gzip-p (search "gzip" (header-in :accept-encoding)))
>
> I think that's a bit too simplistic.  The header could be one of
>
>   Accept-Encoding: x-frogzipper
>   Accept-Encoding: gzip; q=0
>   Accept-Encoding: *

Yeah, you're right. I was just trying to do some experiments and fish
for ideas from the mailing list.

> Something like this maybe (untested):

See? I threw in a brick and got some quality code back. Not bad at all :-)

> I'm not against it per se, but I wouldn't want to add it just for
> static files.

Agreed. I don't think we should put half baked solution into
hunchentoot. For now I'll adopt it into
lsp:create-lsp-folder-dispatcher-and-handler.

Thanks,
-- Mac