-
Notifications
You must be signed in to change notification settings - Fork 48
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
HttpCompression Not Checking for Already Compressed Content #13
Comments
Hello, Kudoz83! In WebMarkupMin 2.2.0 fixed this error. Thanks for information! |
Additionally, this hotfix prevents the occurrence of strange error messages:
Now, instead of it, displays a more understandable error messages:
|
hi i get error
in azure but work fine in my local server, i use 2.2.2 version in my mvc app |
Hello, Sarif! I recommend you to read the “At what point in the run-time process does IIS compress output?” discussion on Stack Overflow. |
Hello, Sarif! You deleted own post? Perhaps you have had a problem with the quotes? |
yes i deleted it,. it already working ,. i add
in my web config i just wondering is it possible to handle it from code,. |
@5arif Add a Also I recommend you to upgrade to version 2.4.0 (there were solved many problems related with HTTP compression). |
Another middleware exists in my pipeline that serves bundled/gziped script and css resources https://github.com/Shazwazza/Smidge
The middleware sets Content-Encoding = gzip since it knows the content it is delivering has already been gziped and cached to disk.
WebMarkupMin does not appear to check the response headers for existing compression before applying its own compression (defaulting to deflate).
I think that if the Content-Encoding header has already been set further down in the pipeline, the WebMarkupMin HttpCompression middleware should be skipped.
In this scenario, content decoding fails at the browser.
Thoughts?
The text was updated successfully, but these errors were encountered: