According to the url() documentation for the 'https' option:

"Whether this URL should point to a secure location. If not defined, the current scheme is used, so the user stays on http or https respectively. TRUE enforces HTTPS and FALSE enforces HTTP, but HTTPS can only be enforced when the variable 'https' is set to TRUE."

However, HTTP can also only be enforced when the variable 'https' is set to TRUE. I have created a patch so that the state of the 'https' variable is only checked if attempting to force HTTPS and not HTTP.

CommentFileSizeAuthor
#12 https-url-932738-12.patch1.37 KBDavid_Rothstein
#2 https.patch1.35 KBspam38
#1 https.patch1.04 KBspam38
https.patch1.06 KBspam38

Comments

spam38’s picture

spam38 commented
StatusFileSize
new https.patch1.04 KB

Adding an alternative patch that doesn't use strict type checking against variable_get('https') to stay consistent with the previous version of the comparison.

spam38’s picture

spam38 commented
StatusFileSize
new https.patch1.35 KB

One more try on the patch, I had to add an else statement to handle a user trying to force HTTPS when the 'https' variable was false.

mfb’s picture

mfb
they or he
commented

And what about sites (such as one of mine) that want to force HTTPS when the 'https' variable is not set?

(In case you're wondering, the reason is that the 'https' variable is used to create insecure session cookies upon HTTPS logins, which for obvious reasons at least some sites will not want to do, but they may still need to generate links or redirects to the HTTPS site from the HTTP site).

chx’s picture

chx commented
Version: 7.0-alpha7 » 8.x-dev
Category: bug » feature

The current https facility is only to supplement the actions of the $conf['https'] setting and the $form['#https'] setting. Doing more is an API change and a feature request. hook_url_outbound_alter is your friend.

mfb’s picture

mfb
they or he
commented

BTW, I added a hook_url_outbound_alter() implementation to http://drupal.org/project/securelogin so sites that don't have $conf['https'] enabled can still link or redirect from the HTTP to HTTPS site.

chx’s picture

chx commented

That's weird. Why did you do that when that module already requires $conf['https'] to be on?

mfb’s picture

mfb
they or he
commented

That module recommends $conf['https'] to be off, I even put it on the module page to make it clear. but sounds like it's not clear enough, I'll rewrite it.

berenddeboer’s picture

berenddeboer commented

Eh really, so we can't force https? And fixing this bug is an API change?? I simply don't get it. If I want to enforce https, I should be able to.

matt2000’s picture

matt2000 commented

@berenddeboer,

I think you're reading it backward. Enforcing HTTPS should work fine. It's the opposite that may not be supported, i.e., forcing an UNsecure url by passing `$options['https'] = FALSE` may be ignored.

dawehner’s picture

dawehner
Primary language German
commented
Issue summary: View changes
Status: Active » Fixed

This variable no longer exists.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

David_Rothstein’s picture

David_Rothstein commented
Version: 8.0.x-dev » 7.x-dev
Component: base system » documentation
Category: Feature request » Bug report
Status: Closed (fixed) » Needs review
StatusFileSize
new https-url-932738-12.patch1.37 KB

Let's put this back to Drupal 7 where it originally was, and fix it as a documentation bug.

David_Rothstein’s picture

David_Rothstein commented
Title: The url() function cannot force HTTP using the 'https' = FALSE option unless the 'https' variable is set. » Document that the url() function cannot force HTTP using the 'https' = FALSE option unless the 'https' variable is set

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.