A client's bug report prompted me to observe the following behavior. IN this case assume I have the path "BBQ" (as in www.mydomain.com/BBQ) added to the list of those paths that should be redirected to SSL via the hook.

-- Access the URL www.mydomain.com/BBQ - result: works as expected, redirects to https
-- Access the URL www.mydomain.com/bbq - result: does not work, no redirect to https
-- Subsequently access the URL www.mydomain.com/BBQ - result: does not work, no redirect to https

uc_ssl appears to be matching paths in a case-sensitive manner. I think this is incorrect, as Drupal's menu system is case-insensitive (mydomain.com/BBQ and mydomain.com/bbq point to the same resource in Drupal).

Furthermore, there seems to perhaps be an interaction between Drupal caching and the case variations, whereby I was able to access the correct URL (mydomain.com/BBQ) without the https redirect if I first accessed it at the incorrect URL (mydomain.com/bbq). But I'm not entirely sure about it.

Making a small change to line 135 changes the regular expression to a case-insensitive criteria, which fixed the problem in my case. I recommend that change be made in the module, to:

$regexp .= ')$/i';

All I've added is the "i" at the end of the $regexp string.

Comments

crystaldawn’s picture

crystaldawn commented

While drupal does allow case-insensitivity, SSL standards do not. This is why this behavior exists. The fix would be to allow a new switch for a url to be sensitive or not. So currently the module behaves correctly according to the standards, but it does have room for improvement in the API. I could add a new switch called "i" which means case insensitive in the array. Another option is to allow other modules to hook into the regex and change/modify it for themselves which would give more flexibility than just adding a switch for case sensitivity. I'll have to think about how this should be dealt with.

YK85’s picture

YK85 commented
Category: bug » feature

subscribing

crystaldawn’s picture

crystaldawn commented
Status: Active » Fixed

I have fixed this by adding a new feature to the administration area. You can turn case insensitivity on/off in the admin area now. It defaults to ON even though that is technically the incorrect SSL way of doing things but currently it is the Drupal way of doing things and we are a drupal module.

Status: Fixed » Closed (fixed)

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