-
Notifications
You must be signed in to change notification settings - Fork 268
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
Set a default Server
header for HTTP responses
#396
Conversation
hi, @adamchainz please take a look This to my knowledge works perfectly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have done a basic review. Please also add a note in CHANGELOG.txt
In |
No heading, as per: 2b6f153 The release version number is determined at release time. Version 3.0.2 is already released. In general, you can check git history on the changelog file to see how a project handles things like this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd also like to see a test for the header on HTTP responses.
hi @adamchainz, The tests should pass now. Thank you so much for guiding a newbie like me and Cheers 🍻 Also a silly question. Does Daphne have a official logo or is there any plan to add one? |
Everything done 😃 Can we merge this now ? Also @adamchainz, Thank you very much for helping me out here. |
I will let @carltongibson make the final review. |
Sure. 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The check being dropped here was added deliberately in #231. So (minor as it is) it's a breaking change and I want to be clear if we're going to proceed.
Andrew's reasoning in #231 was that Server
is not a required (HTTP protocol) header. Autobahn certainly uses it for the WebSocket connection handshake but is that required, I'm not sure. 🤔
I share @adamchainz concern about setting Server headers at all really. ... If we do proceed here, do we have a story for folks not wanting to set that, other than filter it later on? — Why is the response not simply Add a Server header if you want it?
🤔
This comment has been minimized.
This comment has been minimized.
Carlton's point is that he doesn't find "other servers do it" a good enough reason. I can see both sides. Sure, we already send it for websockets, so why not for HTTP responses? And it does help the openness of the web, slightly. Then again, it makes driveby vulnerability scans much easier. We'd rather have a little protection through obscurity if a Daphne/Twisted/whatever exploit is discovered. Perhaps the better approach is actually the opposite: drop
(I don't think this makes it a breaking change - afaict the check was added as a weird way of using "Daphne" a default that meant "don't send a server header".) |
Fair enough.
If thats the goal (having no server header) just run daphne -b 0.0.0.0 -p 8000 core.asgi:application --server-name= This completely removes the server header addition as per #231. While i think that this is not a good implementation. As there should be another option eg:
I agree with you on this.
Let daphne -b 0.0.0.0 -p 8000 core.asgi:application --server-name=gunicorn (which will make daphne indistinguishable from gunicorn) Or if they want to take it to anther level and doesnt wanna show their backend language they can do : daphne -b 0.0.0.0 -p 8000 core.asgi:application --server-name=php to falsify wappalyzer php and gunicorn checks. Some images to back my claims: |
Umm, @carltongibson sorry to ping you. But please tell me, is there anything i need to do for this Pull Request to get merged? |
@baseplate-admin Sorry for the delay — I've had something of a month™. Yes, let's try and get this moving. Reading your last comment, did you prefer the Thanks! |
No problem :D
I prefer For now if you set Eg : daphne -b 0.0.0.0 -p 8000 { asgi_app } --server-name= It will remove the server header altogether. ( For this no extra work needed here | Current Daphne release can do this fine. ) In my opinion it should be better if we passed something like Because it makes the developer aware that they wanna disable a feature, instead of silently disabling it and also because almost 0 production use Eg : daphne -b 0.0.0.0 -p 8000 { asgi_app } --no-server-name Which in return should produce the same result as : daphne -b 0.0.0.0 -p 8000 { asgi_app } --server-name= Now I have a small question. ( Sorry if this sounds stupid )
Edit :
|
I think it's all one issue. If you're happy to add the extra flag, please do so here. |
Hey @carltongibson, I have made the changes. Please take a look. Changes that I have made :
Some Proof of my work ( I ran all of them on this repo ):Default Daphne ( No Flags ) :
PS C:\Programming\Blog-main> pipenv run daphne core.asgi:application
2022-02-12 00:41:10,622 INFO Starting server at tcp:port=8000:interface=127.0.0.1
2022-02-12 00:41:10,622 INFO HTTP/2 support not enabled (install the http2 and tls Twisted extras)
2022-02-12 00:41:10,623 INFO Configuring endpoint tcp:port=8000:interface=127.0.0.1
2022-02-12 00:41:10,624 INFO Listening on TCP address 127.0.0.1:8000
127.0.0.1:61351 - - [12/Feb/2022:00:41:16] "GET /blog/" 200 3458
127.0.0.1:61351 - - [12/Feb/2022:00:41:16] "GET /static/core/css/root.css" 200 144
127.0.0.1:61355 - - [12/Feb/2022:00:41:16] "GET /static/core/css/main.css" 200 181
127.0.0.1:61356 - - [12/Feb/2022:00:41:16] "GET /static/blog/css/blog_list.css" 200 552
127.0.0.1:61357 - - [12/Feb/2022:00:41:16] "GET /static/core/css/navbar/navbar.css" 200 544
127.0.0.1:61358 - - [12/Feb/2022:00:41:16] "GET /static/core/css/footer/footer.css" 200 272
127.0.0.1:61359 - - [12/Feb/2022:00:41:16] "GET /static/blog/js/shapeDividerShadowDom.js" 200 529
127.0.0.1:61351 - - [12/Feb/2022:00:41:16] "GET /static/core/images/logo.png" 200 11449
127.0.0.1:61351 - - [12/Feb/2022:00:41:16] "GET /static/core/vendor/particles.js/particlesjs-config.json" 200 577
127.0.0.1:61356 - - [12/Feb/2022:00:41:16] "GET /static/core/vendor/particles.js/particlesjs-config.json" 200 577
|
Server
header for HTTP responses
@baseplate-admin |
Just giving this pull request a little bump. |
Thanks @baseplate-admin. It's on the list. My aim is to swing back to channels &co once Django 4.1a1 is out of the door. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @baseplate-admin — I rebased and pushed small edits.
Welcome aboard! ⛵
Thank you @carltongibson |
Fixes : #395