-
Notifications
You must be signed in to change notification settings - Fork 179
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
(http server) Do not overwrite response headers with request headers #286
(http server) Do not overwrite response headers with request headers #286
Conversation
Thanks for the PR. Could you add a comment in code that describe why we're doing this. It looks like the server shouldn't win, and trust the client http headers ? Can you check if there's the same problem in the websocket code path ? |
The server shouldn't win? This is the exact opposite - the server is allowing the client to dictate its headers over its own. Which makes no sense. In this case it breaks the server. |
e6ba565
to
4578ba3
Compare
as far as I can tell this is not the case for WS, only HTTP server |
|
Sorry, I really am just contributing a fix to an issue. I will simply maintain a fork with this fix since I don't have time for this anymore. |
No worries, thanks for the contribution @Anna-Boettcher-JPL / I'll try to fix that in the future. |
@bsergean Why is this closed? It's still a bug today. WIthout the fix, all files delivered when USE_GZIP=1 by the httpserver to a browser do not have the Content-Encoding=gzip set as it is overwritten by the client request. This causes the browser to display raw gzip gobbletgook instead of rendering html. Please merge the pull request. |
See my previous comment @glenne
|
When trying to open files served on a local machine with Firefox 87 on Ubuntu 18.04, I discovered a bug where the HttpResponse was overwriting all of its headers with anything in HttpRequest.
In particular this browser had a header
Content-Encoding:
in the request which was eliminating the gzip option specified by the server, but it also doesn't make sense in general to overwrite the response headers with the request headers that have been explicitly set.