Description
What happened?
The WLED HTTP server ignores the "Accept-encoding" header and always returns gzipped content.
To Reproduce Bug
Running curl http://192.168.5.211
will result in a in a bunch of binary gibberish (gzipped compressed content) being dumped to the console. It shouldn't do this because curl
doesn't tell the web server during the request that gzipped content is allowed.
Trying to explicitly deny a gzipped response using curl -sH "Accept-encoding: " http://192.168.5.211
results in the same thing.
Expected Behavior
WLED needs to return a plain, uncompressed response to a request unless the useragent specifically allows a gzipped response.
In my situation, this is preventing me from using Nginx in front of WLED as a SSL proxy. Since WLED has "ws://" hardcoded (bug # #2571), this issue is preventing me from working around the original bug. (The sub_filter
Nginx module can only rewrite uncompressed content).
Install Method
Self-Compiled
What version of WLED?
2202222
Which microcontroller/board are you seeing the problem on?
ESP32
Relevant log/trace output
No response
Anything else?
No response
Code of Conduct
- I agree to follow this project's Code of Conduct