Cannot use connect.compress() middleware with http-proxy #316

fmarier opened this Issue Oct 17, 2012 · 2 comments


None yet

2 participants

fmarier commented Oct 17, 2012

Looking at the middleware example that comes with http-proxy:

I decided to write my own program which makes use of connect.compress() but is otherwise the same as the example that comes with http-proxy:

Unfortunately, it doesn't work because the compress middleware looks at the headers before they are written out in order to decide whether or not a resource should be compressed. I can force compress to always compress everything by calling it like this:

connect.compress({filter: function () {return true;}})

but that's of course not a good idea since images will get gzipped too.

The result is that proxied content is never compressed by connect.compress().

@fmarier fmarier added a commit to fmarier/node-http-proxy that referenced this issue Oct 18, 2012
@fmarier fmarier Set headers prior to calling writeHead() (fixes #316)
This allows the connect.compress() middleware to work on proxied

If this header is not manually set then the compress middleware
will be invoked in the writeHead() call:

before the header has been written. Therefore it will perform its
content-type check:

and so the check will fail and compression will be disabled.

Futhermore, even if that check were bypassed, compress() would be
unable to delete the content-length header:

because by then it wouldn't exist (it will be written after that
header event has been processed by compress). The affect of that
bug is that connections with keep-alive will stall for several
minutes because the browser is waiting for more data (based on
the orignal content-length header, set prior to compression).

i.m.o. this is a bug in connect, as it is perfectly valid to send an object of headers with writeHead. connect patches the writeHead to emit a header event on the response object. The compress middleware is listening to that event to see if it should compress the response, but yet it seems like connect's own documentation suggests that the event is used to add headers just before they are written to the socket, meaning that compress may handle it's header event before something else listening to the event adds a Content-Type header and so compress will miss it. FWIW the header event is not part of node core, it is just something connect patches ServerResponse with.

fmarier commented Oct 22, 2012

@dougwilson is right, it is a problem in connect itself: senchalabs/connect#524

@fmarier fmarier closed this Oct 22, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment