Today, as an example:
If you were running a load balancer on port 80, which proxied back to an
nginx which was running on 8080, it's possible that `get_host()` would
resolve your request back to `example.com:8080` instead of the proper
`example.com` since `SERVER_PORT` is coming from what nginx was listening
on.
This just adds a proper method to `get_port()` and respect an optional `X
-Forwarded-Port` header.
The benefits of this being internal to Django, is because anywhere that
Django tries to resolve the port internally, we should be utilizing this
method. This issue is easy to correct in user-land, but a bit harder when
an internal Django method utilizes `SERVER_PORT` directly. The only option
is to have a middleware which sets `request.META['SERVER_PORT'] =
request.META['HTTP_X_FORWARDED_PORT']` which is less than ideal IMO since
it's overloading the meaning of the variable.
This is also relevant for https://github.com/django/django/pull/4337 since
in the wild, we hit an issue with `SERVER_PORT` not reflecting what the
upstream actually was, which caused issues. So this would unify and make
https://github.com/django/django/pull/4337 leverage the new `get_port()`.
--
Ticket URL: <https://code.djangoproject.com/ticket/25211>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_docs: => 0
* needs_better_patch: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/25211#comment:1>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/25211#comment:2>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"4dcfbd792342667174834c40e792f1b8ac2f0609" 4dcfbd79]:
{{{
#!CommitTicketReference repository=""
revision="4dcfbd792342667174834c40e792f1b8ac2f0609"
Fixed #25211 -- Added HttpRequest.get_port() and USE_X_FORWARDED_PORT
setting.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25211#comment:3>