Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't encode responses with Cache-Control: no-transform #53

Closed
wants to merge 1 commit into from

Conversation

glenjamin
Copy link
Contributor

@@ -135,6 +135,14 @@ function compression(options) {
return
}

// Don't compress for Cache-Control: no-transform
// https://tools.ietf.org/html/rfc7234#section-5.2.1.6
var cacheControl = res.getHeader('Cache-Control') || ''
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this regular expression incorrectly match "foo-no-transform"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm, you're right - I was specifically trying to catch that case!

I'll add some negative tests and improve this - probably split on ,, .trim() and string compare.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did have a look around for an existing lib, but didn't spot anything relevant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there is no existing lib I know of. I was going to write one and put it in the jshttp lib and use it for the implementation of the feature request, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I mean finish the one I started months ago, not start a new one from scratch 😊

@glenjamin
Copy link
Contributor Author

Not the tidiest implementation ever, but should be much more robust than the previous. Thoughts?

@dougwilson
Copy link
Contributor

Hi @glenjamin , sorry, I'm not ignoring you :) Was just swamped today, I'm sure you know how it goes :) Yes, seems good enough for now to accept and eventually swap out with a module sometime in the future (at least we'll have the feature today, which is what matter most ;) . I'll get this merged tonight and then release very soon!

@dougwilson
Copy link
Contributor

As a side note, I've been debating with myself if we should add an option to disable this feature, but IDK, haha. We don't have a switch to turn off Vary.

I also debated with if this detection should be within the shouldCompress function or not (thus allowing people to disable it), but eh :)

This comment was just internal dialog to give to you since you made the PR; not anything that is required to be acted upon :)

@glenjamin
Copy link
Contributor Author

I did wonder about making it configurable or putting into shouldCompress, but came to the same conclusion - if someone's set no-transform, we should never transform.

@glenjamin
Copy link
Contributor Author

Sorry to bump, but is this good to merge? Let me know if some changes are still needed.

@dougwilson
Copy link
Contributor

Hey! Sorry, it is mostly OK, I was going to merge as part of getting this supported with Node.js 4. It also seems to take noticeable time to run this new code, with the split, the some, the trim, and creating a closure. This can easily be reduced to a single regular expression match, but I have not gotten to it, so if you can do that, awesome, otherwise I'll get to it :) so I technically am not waiting on you, haha.

@glenjamin
Copy link
Contributor Author

Updated with a regex, do you have a benchmark suite or something to measure? I could probably poke about and see if there's a faster regex variant.

@dougwilson
Copy link
Contributor

Awesome, @glenjamin , that's it! I should have told you earlier, I'm sorry! As a maintainer, it's always hard to communicate well with people I have not had a history with yet :) Many times, people will just be turned off when there is continued problem noted, so I typically say the first couple, and then adjust after that for a positive experience

@glenjamin
Copy link
Contributor Author

No worries, I've been in your shoes a bunch of times :)

@dougwilson
Copy link
Contributor

I'm just getting some dependency updates in here with your change, just as an update.

@dougwilson
Copy link
Contributor

Any reasoning for choosing to place the check above the Vary response header vs. below it?

@dougwilson
Copy link
Contributor

Published to npm as [email protected]

@glenjamin
Copy link
Contributor Author

RE: Vary - not sure if I thought about it at the time, but I guess since there's no transforming going on so nothing varies?

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

Successfully merging this pull request may close these issues.

2 participants