You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DB system (MySQL, Blazegraph, etc.) and version: MySQL-5.7.32-0ubuntu0.16.04.1
Elasticsearch version: 5.6.16
Issue
This issue came to light after having found the cause of #4488. In the ElasticSearch file ingestion process, a call is made to the get_headers() function in the FileHandler class (here) using a URL that is based on $wgServer.
According to the documentation of $wgServer, MediaWiki supports setting it to a protocol-relative URL (e.g., //www.mediawiki.org). Doing this however causes the previously mentioned call to get_header() to fail, since it is unable to recognize the given URL as a valid URL:
PHP Warning: get_headers(): This function may only be used against URLs
This causes the get_headers() function to return false, which causes the file ingestion to fail. This should not happen, since a protocol-relative $wgServer should be allowed.
Steps to reproduce the observation:
Set $wgServer to a protocol-relative URL (e.g. //www.mediawiki.org)
Enable experimental.file.ingest for ElasticStore
Run rebuildElasticIndex maintenance script
The text was updated successfully, but these errors were encountered:
26
added
the
bug
Occurrence of an unintended or unanticipated behaviour that causes a vulnerability or fatal error
label
Jan 22, 2021
Setup
Issue
This issue came to light after having found the cause of #4488. In the ElasticSearch file ingestion process, a call is made to the
get_headers()
function in the FileHandler class (here) using a URL that is based on$wgServer
.According to the documentation of $wgServer, MediaWiki supports setting it to a protocol-relative URL (e.g.,
//www.mediawiki.org
). Doing this however causes the previously mentioned call toget_header()
to fail, since it is unable to recognize the given URL as a valid URL:This causes the
get_headers()
function to returnfalse
, which causes the file ingestion to fail. This should not happen, since a protocol-relative$wgServer
should be allowed.Steps to reproduce the observation:
$wgServer
to a protocol-relative URL (e.g.//www.mediawiki.org
)experimental.file.ingest
forElasticStore
rebuildElasticIndex
maintenance scriptThe text was updated successfully, but these errors were encountered: