Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

gzip support and more consistent headers sent to HEAD #34

Closed
wants to merge 6 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

dobesv commented Nov 2, 2011

This patch includes support for gzip. It will serve up a static .gz file matching the normal uncompressed file, if it finds one. It must be enabled in the options and the user-agent must specify accept-encoding: gzip. It doesn't do any compression on the fly, so there's no performance penalty worth mentioning.

I think this is a good improvement since if you are actually serving up static files using your node server (as opposed to an nginx proxy in front) you should really support compression for those files where possible as it can greatly speed up the browsing experience.

This system is compatible with http://wiki.nginx.org/HttpGzipStaticModule so you have a simple migration path to an nginx front-end if you later decide to offload the work of sending static files.

dobesv added some commits Nov 2, 2011

@dobesv dobesv Add static gzip file support, where a gzip file with a matching name …
…but adding .gz to the end can be served up to clients that support it. As part of that, changed the code so the Content-Type and Content-Length are sent even for an HTTP HEAD request.
1a88cad
@dobesv dobesv Updated the README to describe gzip configuration 77fcd6f
Contributor

dobesv commented Nov 2, 2011

Note: fixes #20

nambrot commented Dec 29, 2011

Im looking into this commit, but I couldn't help and wondering, whether it is really necessary to remove the in-memory cache?

Contributor

dobesv commented Dec 30, 2011

Well the in memory cache is buggy right now and I didn't see fit to fix
it. I opened a separate issue discussing that.
On Dec 30, 2011 5:19 AM, "nambrot" <
reply@reply.github.com>
wrote:

Im looking into this commit, but I couldn't help and wondering, whether it
is really necessary to remove the in-memory cache?


Reply to this email directly or view it on GitHub:
#34 (comment)

Contributor

dobesv commented Dec 30, 2011

My notes about the in memory cache issues are here:

#36
On Dec 30, 2011 9:01 AM, "Dobes Vandermeer" dobesv@gmail.com wrote:

Well the in memory cache is buggy right now and I didn't see fit to fix
it. I opened a separate issue discussing that.
On Dec 30, 2011 5:19 AM, "nambrot" <
reply@reply.github.com>
wrote:

Im looking into this commit, but I couldn't help and wondering, whether
it is really necessary to remove the in-memory cache?


Reply to this email directly or view it on GitHub:
#34 (comment)

@phstc phstc closed this Jul 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment