Last modified: 2012-04-12 14:00:08 UTC
PHP Notice: Uninitialized string offset: 0 in \includes\WebRequest.php on line 461 I can't figure out if this is an OpenID issue or MW, but 100% replicable (at least using IIS/IE) Problem is $_SERVER['REQUEST_URI'] is set, but value "" when it gets to getRequestURL Some Debug Information: WebRequest::getRequestURL::REQUEST_URI:** WebRequest::getRequestURL::SCRIPT_NAME:*/TestWiki/index.php* BackTrace::(870) includes\SkinTemplate.php::getRequestURL args: 0 BackTrace::(490) includes\SkinTemplate.php::buildContentActionUrls args: 0 BackTrace::(1572) includes\OutputPage.php::outputPage args: 1 BackTrace::(376) includes\Wiki.php::output args: 0 BackTrace::(118) index.php::finalCleanup args: 2 Could definitely fix this by patching MW to on line 439 to: if( isset( $_SERVER['REQUEST_URI'] ) && strlen($_SERVER['REQUEST_URI'] )) { But I'm wondering if this might result from an anomaly further back in the OpenID extension.
Oh, I should also have mentioned this is occurring using myopenid, although I haven't tested with any of the others.
Hmm. I never has this issue, although my instances only run on Linux. I only see PHP Notice above - is there an error somewhere? Can you describe how it manifests itself to the user?
IIS doesn't seem to support $_SERVER['REQUEST_URI'] http://davidwalsh.name/iis-php-server-request_uri
In answer to your questions: 1. The error(warning) is only generated into the phperrors.log 2. It manifests itself because (regardless), on successful login you're always taken back to "main page". I think Platonides probably has it right. Is there somewhere that OpenID is initializing $_SERVER['REQUEST_URI'] and if so, should it be initializing it as above? And if not, should it be formatting a query_string for IIS instead of assuming REQUEST_URI will do the job (as indidicated in http://davidwalsh.name/iis-php-server-request_uri)?
$_SERVER['REQUEST_URI'] is supposed to be initialized by PHP actually. REQUEST_URI apparently is not even used anywhere in OpenID extension or library - I grep'd the whole thing for it ;) So it's probably unrelated to OpenID. Why do you think it has anything to do with it?
I agree - grepped the whole thing too with same results. The only time I get this error is when I'm logging in using OpenID - otherwise it may be completely unrelated - unless of course OpenID assumes that the original URI can be passed in REQUEST_URI and does not use the "QUERY_STRING" to pass forward the parameters (as required for IIS). In any case this is undoubtedly an IIS related issue and the obvious answer to it is "why are you using IIS, you dork"!!! (a situation I intend to remedy sooner rather than later) I'm going to see if I can get someone to look and see if this is a global web request error, I think the above patch would fix webrequest, but don't want to add it until someone with more experience reviews.
Created attachment 7456 [details] Patch for IIS "doesn't use $_SERVER['REQUEST_URI']" issue This is conjecture, but I believe one of the patches to IIS and/or PHP has made it so that $_SERVER['REQUEST_URI'] is no longer "undefined", but rather just returned as ''. This patch would fix that. CAVEAT: I do not know if there is a valid condition under which the REQUEST_URI would be blank in a non-IIS environment. Someone who knows this code and its purpose should look at this to make sure such a patch wouldn't uninentionally break a $_SERVER['REQUEST_URI'] == '' condition that is valid for reasons other than IIS doesn't use it. If someone can validate this would not cause other errors, I'd be glad to commit to both 1.16beta03 and trunk.
> In any case this is undoubtedly an IIS related issue and the obvious answer to > it is "why are you using IIS, you dork"!!! (a situation I intend to remedy > sooner rather than later) We need some developers running IIS. We don't want to be in a situation where the only people reporting IIS bugs are clueless users. I would say stick with it, if you're interested in improving support for it.
