Add option to `build_absolute_uri` to build specific http or https URI

[Rik]

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)

[Tim Graham]

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.

[Rik]

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.

[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://".

[Natalia Bidart]

Chris, I believe that this ​forum post from Carlton could help with this issue. The post is about something slightly different, but in there they link to ​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.