securepages_form_alter() changes form action inappropriately if parse_url($form['#action']) fails

I work on a site where we display a EULA form (showing the site's end user license agreement with a checkbox stating "I've read and agree to these terms") to users logging in for the first time via OpenID. When the EULA is displayed, the user's OpenID URL is contained in the URL for the page.

On my testing server, a Mac running PHP 5.3.15, the EULA form worked just fine; but when we went live, to a Windows server running PHP 5.2.17, I found that the action attribute on the EULA form was being set to the homepage instead of the proper url (which would be something in the format of "/openid-login?openid_identifier=https://www.joeschmo.biz/openid/joe").

After some digging, I found that this was because the Windows server couldn't handle a call to parse_url('/openid-login?openid_identifier=https://www.joeschmo.biz/openid/joe'). Because parse_url() was failing, the $path variable wasn't being set by expand() -- so further down in the securepges_form_alter() function, where the $path variable is assumed to contain the path component of the form action URL, it's actually undefined.

I've stepped around this issue by following markDrupal's suggestion, from June 5, 2009, in response to issue #420110 -- only I've kept the @'s for good measure. In place of:

@extract(@parse_url($form['#action']));

I now have:

$url_parts = @parse_url($form['#action']);
if($url_parts === false) return;
@extract($url_parts);

And this seems to do the trick: form actions that parse_url() chokes on are simply ignored by securepages_form_alter(), instead of being erased.

As an aside: I've marked the Version as 6.x-1.x-dev, because that's the version this site appears to be running (the $id tag at the top of securepages.module says: "$Id: securepages.module,v 1.15.2.28 2011/02/23 14:41:39 gordon Exp $"), but it looks to me like this issue would affect 6.x-2.x and possibly even the 7.x branches as well.