Comments (11)
It's a great idea! I agree you should be able to, at minimum, decide which of the built-in encoding to enable.
from compression.
I thought it would only use deflate as a last resort and when the client accepted it?
from compression.
Right. AFAIK, IE always sends Accept-Encoding: gzip, deflate
, and this module prefers gzip
over deflate
, which means that IE, by default, will never get a deflate response (which probably also explains why no one has ever brought this up in this module before, especially since it has been like this since at least 2012).
from compression.
@gfemec can you provide details on the browser setup that causes this?
from compression.
I also went ahead and read about this whole deflate thing with wrapped vs unwrapped stream and was thinking perhaps to just emit an unwrapped stream, but changed my mind when I read the latest HTTP RFCs (RFC 7230 section 4.2.2: https://tools.ietf.org/html/rfc7230#section-4.2.2) which made it clear which format was the "conforming" one.
One thing we could potentially do is prefer gzip
over deflate
, even if the client wants deflate
more (or, at least, do it when both gzip
and deflate
are preferred by the client at the same quality level).
from compression.
Sorry, this gets a bit specific to my setup. I am using a CDN, and the CDN inspects the Accept-Encoding
header to determine which cached responses to send to the client. On cache miss the CDN modifies the request to my origin to include Accept-Encoding: deflate;q=1.000, gzip;q=0.999, identity;q=0.001
(ostensibly because deflate is faster than gzip) which receives a deflate'd response. Then the CDN serves this cached response to all browsers that claim to accept deflate which causes the problem on IE. I realize I could work with the CDN to change this behavior but in researching this I found a common recommendation was to disable DEFLATE entirely.
http://stackoverflow.com/questions/388595/why-use-deflate-instead-of-gzip-for-text-files-served-by-apache
http://zoompf.com/blog/2012/02/lose-the-wait-http-compression (GZIP vs DEFLATE)
No worries if you'd rather not add complexity for this edge use-case, I have already fixed my issue by modifying the accept header from the CDN but I just figured it might be a useful option to have for this middleware.
from compression.
but I just figured it might be a useful option to have for this middleware.
It's no problem. I 100% agree that you should be able to turn certain encodings off, as per your original request :) I'm really glad, through, that @Fishrock123 got you to explain a little more, because ideally, we'd also like to make it work better :)
modifies the request to my origin to include Accept-Encoding: deflate;q=1.000, gzip;q=0.999, identity;q=0.001
ah, i see. One idea I was also floating in my head was perhaps to just prefer gzip
no matter what, as long as the client said it wanted it (or, conversely, only use deflate
as a last resort).
from compression.
Great, just to be clear all I was proposing was an option to disable an encoding. I'm in complete agreement that the deflate
responses are correct as they are and also think the way the Accept-Encoding
header is being interpreted is correct. Would you like a PR that adds an option to specify a list of allowed encodings?
from compression.
Would you like a PR that adds an option to specify a list of allowed encodings?
Yes, if you're willing. I'm' going to implement this anyway, so don't feel pressured to make one :)
So to be clear: I agree that the user should be able to choose which encodings to enable/disable (i.e. you should be able to only allow gzip, if you wish). All other discussion in here is just in general, stemmed from your original feature request, in the interest in just making the module better in general :)
from compression.
Ok, as of version 1.4.0, your original issue should be no more, as we'll still send gzip
coding, even to that proxy. As for controlling, I have an API that is very flexible, but is not backwards-compatible, so I'm pushing it to v2.
from compression.
Side topic, if you need a workaround; theoretically you should be able to insert a simple bit of middleware before compression that simply edits the Accept-Encoding
header and removes the deflate
algorithm from it. Then the compression middleware will never think a request supports deflate compression.
from compression.
Related Issues (20)
- Setting Vary header although caching is disabled HOT 1
- "drain" event listener leak when using res.once("drain"); can't use res.removeListener("drain") HOT 3
- compresssion doesn't work ,the vue.txt is 2m HOT 2
- Content-Type: application/json; charset=utf-8 No effect HOT 2
- Question: Why this middleware HOT 2
- Corrupted compressed .js-files for Mac OS / Safari -clients HOT 11
- Is compression working when node server is running on a container? HOT 2
- middleware fails when the request has more than 1 values for accept-encoding header HOT 2
- Is compression result cached? HOT 1
- change Transfer-encoding HOT 1
- Why does the data size increase after compression HOT 1
- Force size to be a minimum... HOT 2
- Chunked encoding is broken after using this middleware HOT 1
- Using a current debug version HOT 1
- Deflate backwards HOT 7
- Compression instrumentation (before/after compression hooks) HOT 2
- Angular Not Compressing? HOT 2
- compression not working json payload HOT 6
- Crash when compressing characters like ū HOT 1
- Express returns a non-compliant HTTP/206 response when gzip is enabled HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compression.