Fatal MWException on every page when using InstantCommons (PHP < 5.3.21, 5.4.11; libcurl >= 7.28.1)
Closed, ResolvedPublic

Description

Like bug 42441?


Error setting curl options.

Backtrace:
#0 ../includes/filerepo/ForeignAPIRepo.php(403): CurlHttpRequest->execute()
#1 ../includes/filerepo/ForeignAPIRepo.php(164): ForeignAPIRepo::httpGet('http://commons....')
#2 ../includes/filerepo/file/ForeignAPIFile.php(61): ForeignAPIRepo->fetchImageQuery(Array)
#3 [internal function]: ForeignAPIFile::newFromTitle(Object(Title), Object(ForeignAPIRepo))
#4 ../includes/filerepo/FileRepo.php(325): call_user_func(Array, Object(Title), Object(ForeignAPIRepo))
#5 ../includes/filerepo/ForeignAPIRepo.php(95): FileRepo->newFile(Object(Title), false)
#6 ../includes/filerepo/FileRepo.php(354): ForeignAPIRepo->newFile(Object(Title))
#7 ../includes/filerepo/RepoGroup.php(151): FileRepo->findFile(Object(Title), Array)
#8 ../includes/GlobalFunctions.php(3472): RepoGroup->findFile(Object(Title), Array)
#9 ../includes/Title.php(4228): wfFindFile(Object(Title))
#10 ../includes/Title.php(4255): Title->isAlwaysKnown()
#11 ../includes/Linker.php(224): Title->isKnown()
#12 ../includes/Linker.php(1403): Linker::link(Object(Title), 'Klassieke terra...')
#13 [internal function]: Linker::formatLinksInCommentCallback(Array)
#14 ../includes/Linker.php(1337): preg_replace_callback('/?????\[\[?????...', Array, 'Nieuwe pagina a...')
#15 ../includes/Linker.php(1213): Linker::formatLinksInComment('Nieuwe pagina a...', Object(Title), false)
#16 ../includes/Linker.php(1509): Linker::formatComment('Nieuwe pagina a...', Object(Title), false)
#17 ../includes/Linker.php(1532): Linker::commentBlock('Nieuwe pagina a...', Object(Title), false)
#18 ../includes/actions/HistoryAction.php(610): Linker::revComment(Object(Revision), false, true)
#19 ../includes/actions/HistoryAction.php(491): HistoryPager->historyLine(Object(stdClass), NULL, false, false, false)
#20 ../includes/Pager.php(428): HistoryPager->getEndBody()
#21 ../includes/actions/HistoryAction.php(188): IndexPager->getBody()
#22 ../includes/Action.php(541): HistoryAction->onView()
#23 ../includes/Wiki.php(427): FormlessAction->show()
#24 ../includes/Wiki.php(304): MediaWiki->performAction(Object(Article))
#25 ../includes/Wiki.php(536): MediaWiki->performRequest()
#26 ../includes/Wiki.php(446): MediaWiki->main()
#27 ../index.php(59): MediaWiki->run()
#28 {main}


Version: 1.20.x
Severity: major
URL: https://www.mediawiki.org/w/index.php?title=Manual_talk:$wgUseInstantCommons&diff=next&oldid=630577
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42441
https://bugzilla.wikimedia.org/show_bug.cgi?id=70262

Details

Reference
bz44135
bzimport set Reference to bz44135.
bzimport added a subscriber: Unknown Object (MLST).

arent wrote:

"Fatal exception of type MWException"

Every page containing a link to a picture on commons results in an error.

On local upload I also get the same error (does reference the same commons file first). Whenever I set $wgUseInstantCommons to false the errors keep away; the pictures too...

Please try the fix of bug 42441 and see if it fixes it:
Change protected $sslVerifyHost = true; to protected $sslVerifyHost = 2; on
the beginning of MWHttpRequest (around line 190 of includes/HttpFunctions.php), and report if it fixes your problem.

arent wrote:

$sslVerifyHost = 2

seems to work ;-)

I guess Ia6535f10 needs to be backported to 1.20?

This bug was the same as bug 42441 but for MediaWiki 1.20. Got fixed by backporting the fix :-)

  • Bug 45339 has been marked as a duplicate of this bug. ***

@mark and whomever: *Please* make a 1.20.x release with this bug fix.

It has been backported to REL1_20, release notes have been prepped.

Any third-party using InstantCommons with the default settings is currently broken. Any page that embeds an image anywhere in the page or from a transcluded template does not render.

The entire page is not rendered, instead a red error is shown with an MWException pointing to CurlHttpFunctions being unable to make the request to commons.wikimedia.org.

Krinkle, we currently have no way to track such things, you should perhaps file a new bug to track whether the fix for this is available in the last tarball.
We have worse critical bugs in 1.20.2, it's a very unfortunate release.

Though it is commonly in PHP 5.3.x environments it can happen in PHP 5.4.x too. It depends on which version of curl php is built against.

See:

As of PHP 5.3.21, 5.4.11, it will inspect this value and silently fix it for libcurl >= 7.28.1 whilst emitting a deprecation notice.

Just to clarify Arent's comment, updating line 188 of includes/HttpFunctions.php to set $sslVerifyHost = 2 instead of 'true' is an easy fix for this issue on systems where php+libcurl have been updated to not allow 'true'.

We'll be releasing an updated for this issue as part of 1.20.3 in the next few days.

Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptJan 28 2016, 6:02 PM

Add Comment