Corrects bug with using compress and staticCache together. #458

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

ryanrolds commented Jan 15, 2012

No description provided.

+app.use(connect.staticCache());
+app.use(connect.static(fixtures));
+
+describe('connect.staticCache() & connect.compress()', function(){
@tj

tj Jan 15, 2012

Member

could we move these to test/staticCache.js as describe('Vary', or something similar

@ryanrolds

ryanrolds Jan 15, 2012

Contributor

Yes, but do we want to mix the tests? Right now the test for staticCache doesn't use the compress middleware.

@tj

tj Jan 15, 2012

Member

nvm i thought these were for negotiating via Vary at a glance

lib/middleware/staticCache.js
+ res.setHeader(field, header[field]);
+ });
+
+ res.writeHead(200);
@tj

tj Jan 15, 2012

Member

node defaults it to 200 so we shouldn't need this

@ryanrolds

ryanrolds Jan 15, 2012

Contributor

Good point. I will take care of that.

@ryanrolds

ryanrolds Jan 15, 2012

Contributor

Just updated the pull with a commit that removes the call to writeHead()

lib/middleware/staticCache.js
+ // needed to deal with compress conflict
+ Object.keys(header).forEach(function(field) {
+ res.setHeader(field, header[field]);
+ });
@tj

tj Jan 15, 2012

Member

i might be missing something but wouldn't this be pretty much identical to the old res.writeHead call?

@ryanrolds

ryanrolds Jan 15, 2012

Contributor

One major difference, it doesn't trigger the header event. When the header event is fired, compress checks the headers but the new headers (specifically the Content-Type) haven't been set yet. The compress middlware doesn't compress if the Content-Type is missing.

@tj

tj Jan 15, 2012

Member

hmm every response should have a "header" event at some point, but that's a connect thing in patch.js, if it doesn't it's a bug

@ryanrolds

ryanrolds Jan 15, 2012

Contributor

Yeah, I saw it in patch.js. The issue is the header event is emitted before the headers in arguments[1] are applied, so when the compress middleware tries to get the Content-Type header in filter() it doesn't exist yet.

@tj

tj Jan 15, 2012

Member

right ok I think I get what you mean now. That's what really blows about node's different APIs for the same task haha. If writeHead() used setHeader internally we'd probably be fine but I gotcha

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