Wikimedia Bugzilla is closed!

PHP Notice:  Uri::parseUri: Invalid scheme in URL: callto [Called from Uri::setUri in /www/w/includes/Uri.php at line 111] in /www/w/includes/GlobalFunctions.php on line 1070

Need more context on this (what were you doing when you received this notice).

The warning shown is called when a URI finds a protocol not in $wgUrlProtocols. In this case it seems a URL is being parsed where the protocol is "callto", but I cannot determine where such a URL is being generated.

Can you make it output more useful error output? I don't have time to debug every issue seen at translatewiki.net myself (unless you ask nicely :).

Clarification: We have a bot announcing all notices in our IRC channel, so I have no idea what the users are doing to cause it.

It vaguely reminds be of the feature of the Firefox Skype plugin
to put some funny stuff in the text when editing.

Maybe something like a Skype plugin is converting text looking like a phone number
to callto: links?

Ah OK. Didn't realize this was bot realized. I'll see if I can try and reproduce it. And Marcin may be onto something.

The easiest way to fix this (and probably the way it will be fixed), will be to add "callto" to the list of allowed protocols, but I want to make sure where this URL is coming from before doing so.

One more:
[07-Aug-2012 18:55:27] PHP Notice:  Uri::parseUri: Invalid URL: http:// [Called from Uri::setUri in /www/w/includes/Uri.php at line 111] in /www/w/includes/GlobalFunctions.php on line 1070

But the foreach (the subject) is the most noisiest, about ten times in an hour.

So to list the problems:

1) foreach error - No idea why this is happening. This is a bug in the core.
2) callto scheme error - Can be fixed by adding "callto:" to allowed protocols.
3) invalid URL error - This is because PHP's parse_url does not handle empty URLs, i.e., only a protocol.

I cannot seem to reproduce any of these errors on a base MW installation unfortunately, but I'm still looking. Hopefully somebody else has an idea of where these invalid URLs are coming from. The only reason you're getting these warnings now and not previously is because the original URL functions just returned false on error rather than actually issuing a warning.

>The only reason you're getting these
>warnings now and not previously is because the original URL functions just
>returned false on error rather than actually issuing a warning

Returning false sounds like the more desired behaviour. If the issue is really something that cannot be ignored, an exception should be thrown. PHP notices are icky. (In this case, I think wfDebug is more appropriate than wfWarn).

>2) callto scheme error - Can be fixed by adding "callto:" to allowed protocols.

If the issue is that Uri.php fails badly when fed an invalid url, making all urls valid is not a good solution, as it would defeat the point of doing url validation.

(In reply to comment #9)
> >The only reason you're getting these
> >warnings now and not previously is because the original URL functions just
> >returned false on error rather than actually issuing a warning
> 
> Returning false sounds like the more desired behaviour. If the issue is really
> something that cannot be ignored, an exception should be thrown. PHP notices
> are icky. (In this case, I think wfDebug is more appropriate than wfWarn).
> 
> >2) callto scheme error - Can be fixed by adding "callto:" to allowed protocols.
> 
> If the issue is that Uri.php fails badly when fed an invalid url, making all
> urls valid is not a good solution, as it would defeat the point of doing url
> validation.

I agree, and most likely a switch to wfDebug will be the answer, but I'm still wondering why and in what context MW would be using invalid URLs like that.

The change(s) should be reverted if the fix is not coming in very soon.

These issues are not bugs with the Uri.php change, but rather are previously unnoticed issues with MW's calls to wfUrlParse(), so reverting the change would be counterproductive.

However, issues 2 and 3 should have been fixed in https://gerrit.wikimedia.org/r/18059

And issue 1 has been fixed: https://gerrit.wikimedia.org/r/18181

That didn't fix the problem. Our channel was flooded with during the night:
[09-Aug-2012 06:04:45] PHP Warning:  Invalid argument supplied for foreach() in /www/w/includes/Uri.php on line 262

Please fix or revert ASAP, master should always work!

<li>Uri.php line 263 calls wfBacktrace()</li>
<li>GlobalFunctions.php line 486 calls Uri->extendQuery()</li>
<li>OutputPage.php line 402 calls wfAppendQuery()</li>
<li>Gadgets_body.php line 226 calls OutputPage->addScriptFile()</li>
<li>Gadgets_body.php line 196 calls GadgetHooks::applyScript()</li>
<li>- line - calls GadgetHooks::beforePageDisplay()</li>
<li>Hooks.php line 216 calls call_user_func_array()</li>
<li>GlobalFunctions.php line 3897 calls Hooks::run()</li>
<li>OutputPage.php line 1995 calls wfRunHooks()</li>
<li>Wiki.php line 543 calls OutputPage->output()</li>
<li>Wiki.php line 446 calls MediaWiki->main()</li>
<li>index.php line 58 calls MediaWiki->run()</li>
</ul>

3943299 <- value passed in

I am also getting this error in my http error file


[Thu Aug 09 00:43:07 2012] [error] [client {IP}] PHP Warning:  Invalid argument supplied for foreach() in {dir}/w/includes/Uri.php on line 262, referer: http://internationalguidetoavoiddying.com/wiki/{page}

This happens when any page is loaded

I'm guessing that $parameters is not an array (but is something that allows count to return true..) at the point of iteration

Add a is_array( $parameters ) && ?

Which presumably it wasn't decided to be a string when it was passed in either

It's int. count returns 1 for any non-array which is not false-like.

and for every page load it gives four of these errors is there any other information i can provide to help?

(In reply to comment #17)
> I'm guessing that $parameters is not an array (but is something that allows
> count to return true..) at the point of iteration
> 
> Add a is_array( $parameters ) && ?
> 
> Which presumably it wasn't decided to be a string when it was passed in either

https://gerrit.wikimedia.org/r/#/c/18232/

Success! Finally figured out what the problem is. It seems certain components (such as the Gadgets extension) are passing numeric queries. Uri::extendQuery() is coded to pass any strings to wfCGIToArray, but doesn't account for the fact that the parameter can be an integer. A patchset will be submitted shortly.

https://gerrit.wikimedia.org/r/18237

(In reply to comment #15)
> 3943299 <- value passed in

		$u = $t->getLocalURL( 'action=raw&ctype=' . $wgJsMimeType );
		$out->addScriptFile( $u, $t->getLatestRevID() );

https://gerrit.wikimedia.org/r/#/c/18232/

patch 2..

(In reply to comment #22)
> https://gerrit.wikimedia.org/r/18237

(In reply to comment #23)
> (In reply to comment #15)
> > 3943299 <- value passed in
> 
>         $u = $t->getLocalURL( 'action=raw&ctype=' . $wgJsMimeType );
>         $out->addScriptFile( $u, $t->getLatestRevID() );
> 
> https://gerrit.wikimedia.org/r/#/c/18232/
> 
> patch 2..

I've removed the count call as it's superfluous, if we make sure there's an array to iterate over it..

Seams to have worked :) pages load ... and no errors ... I think you can close this bug :) and thank you very much :)