[Django] #24459: Add option to `build_absolute_uri` to build specific http or https URI
Django
-------------------------------+--------------------------------
Reporter: rednaw | Owner: nobody
Type: Uncategorized | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Keywords: build_absolute_uri
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------
The `build_absolute_uri` method on the request object
(https://docs.djangoproject.com/en/1.7/ref/request-response/) builds an
absolute URI to the given location. It takes the protocol you're currently
on, so if you are on `http://example.com` and you execute
`build_absolute_uri('test/')` you'll get `http://example.com/test/`, and
if you're on `https://example.com`, you'll get
`https://example.com/test/`.
Sometimes when I create an absolute uri, I want to be sure that it's going
to https, whether I currently am on http or https. So I would like it if I
could tell this to the `build_absolute_uri` method.
I propose to add a keyword agrument `https` to the method. When you set it
to `True` it will use https, when you set it to `False` it will use http,
and when you don't set it it will default to `null`, which will keep the
old behavior (use the protocol that's in use in the current request).
So then you would be able to create a secure absolute URI like this:
{{{
build_absolute_uri('test/', https=True)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24459>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: rednaw | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: master
Keywords: build_absolute_uri | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* type: Uncategorized => New feature
* needs_tests: => 0
* needs_docs: => 0
Comment:
For the parameter name, `secure` might be more in line with other parts of
Django. I guess you meant `None` (rather than `null`) for the default.
--
Ticket URL: <https://code.djangoproject.com/ticket/24459#comment:1>
Django
Reporter: rednaw | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: master
Keywords: build_absolute_uri | Triage Stage:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by rednaw):
* stage: Accepted => Someday/Maybe
Comment:
I had some discussion with Erik and Markus about this and we came to the
conclusion this feature is probably not necessary and could encourage
people to mix http and https on one domain.
The point is that mixing http and https on one domain is a bad practice
for several reasons, and if you have https support anyway, there's no
straightforward reason to not use it everywhere.
So I was thinking on elaborating this in the Django documentation of
`build_absolute_uri` instead. Explain why the method doesn't support
scheme switching.
--
Ticket URL: <https://code.djangoproject.com/ticket/24459#comment:2>
Django
Reporter: rednaw | Owner: nobody
Type: New feature | Status: closed
Component: HTTP handling | Version: master
Keywords: build_absolute_uri | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by rednaw):
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/24459#comment:3>
Django
Reporter: Rik | Owner: nobody
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: build_absolute_uri | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Chris Spencer):
I think the response here misses the point. Yes, everyone agrees that
https should be used everywhere publicly. That's the problem. Currently,
`build_absolute_uri` does not do that. In some environments, SSL is
handled by a public facing load balancer which redirects them as non-SSL
requests to a non-public pool of servers. Those servers don't use SSL to
make request handling faster and simplify SSL certificate management, and
since they're not publicly accessible, that's fine. In that situation,
Django only see http, causing `build_absolute_uri` to only build non-SSL
URLs. Having some option to force it to use https would be more convenient
that having to do a str.replace or slice+concat to convert "http://" to
"https://".
--
Ticket URL: <https://code.djangoproject.com/ticket/24459#comment:4>
Django
Reporter: Rik | Owner: nobody
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: build_absolute_uri | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Natalia Bidart):
Chris, I believe that this [https://forum.djangoproject.com/t/do-we-need-
an-easier-toggle-for-request-is-secure-to-be-true/20751/1 forum post from
Carlton] could help with this issue. The post is about something slightly
different, but in there they link to [https://noumenal.es/notes/til/django
/csrf-trusted-origins/ another post] where they talk about a analogous
scenario (doing SSL termination separately from your app servers and
dealing with `request.is_secure()` returning `False`) which I think
relates to how Django decides whether to use `http` or `https`.
--
Ticket URL: <https://code.djangoproject.com/ticket/24459#comment:5>