Skip to content
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

bpo-38907: In http.server script, restore binding to IPv4 on Windows. #17851

Merged
merged 2 commits into from
Jan 6, 2020
Merged

bpo-38907: In http.server script, restore binding to IPv4 on Windows. #17851

merged 2 commits into from
Jan 6, 2020

Conversation

jaraco
Copy link
Member

@jaraco jaraco commented Jan 6, 2020

This PR takes a more surgical approach to GH-17378, addressing only the regression introduced with the dual-stack support added in 3.8 for the http.server command. Presumably, better support will be added to the HTTPServer and TCPServers for dual-stack support in bpo-25667 or bpo-20215, but this PR aims to minimally restore the prior expectation and not affect the behavior of those classes.

I considered writing tests for this change, but the existing tests for the http.server command mock out the intended behavior, so I've instead tested the change by applying the patch to Python 3.8.1 on Windows and confirmed it has the intended effect.

https://bugs.python.org/issue38907

@jaraco jaraco merged commit ee94bdb into python:master Jan 6, 2020
@jaraco jaraco deleted the bugfix/38907-restore-ipv4-bind-windows branch January 6, 2020 03:32
@miss-islington
Copy link
Contributor

Thanks @jaraco for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

@bedevere-bot
Copy link

GH-17854 is a backport of this pull request to the 3.8 branch.

@jaraco
Copy link
Member Author

jaraco commented Jan 6, 2020

This change is unsuitable; the call to setsockopt needs to be called only when the socket is using IPv6 protocol.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants