/ waitress Public
Cleanup: Server Name deduction logic #329
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
Waitress always used to assume that it would be running on a system where there was a correctly implemented DNS system that would return the hostname when doing a reverse DNS lookup on the IP address it was bound to, or that the system would return the IP address itself.
This is however not the case as seen in #312, #283, #268, #311 and issues in #149.
So now the logic is simplified even further. We don't attempt do anything of the sort anymore at all. Waitress has learned a new configuration value called
server_name. The default is
The only time that a user will see this value if the following is true: the request arrives over HTTP 1.0 and the remote client does not set a Host header.
In no other situation does the
server_namevalue, which is used in the WSGI environment
SERVER_NAMEmatter because it should be overridden with the
Hostheader sent by the client, or if using a Proxy, can be set on