Page MenuHomePhabricator

VisualEditor throws "Error contacting the Parsoid/RESTBase server (HTTP 500)" on fresh installation
Open, HighPublic


I made a fresh installation of MediaWiki 1.35 and didn't activated anything special while installation. After the wiki was up and running I added the following line to LocalSettings.php: wfLoadExtension( 'VisualEditor' );
Nothing else was modified.

When trying to edit a page with VisualEditor I receive the following error consistently: "Error contacting the Parsoid/RESTBase server (HTTP 500)"
My understanding is, that there shouldn't be any additional config steps to make it work?!

My setup:

  • Local raspian server that is no reachable from the internet (Linux xxxxxx 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux)
  • apache2.4.38 with php7.3.19
  • Wiki is configured to be editable by everyone
  • no RewriteRules in vhost config or .htaccess

A found a lot of other reports via google about the same or similar problems but unfortunately I wasn't able to find a solution.

If I missed any important info please let me know.

Any help would be highly appreciated!


Event Timeline

If relevant, here are my installed packages (related to apache or php) via APT on this server:

apache2-bin/stable,now 2.4.38-3+deb10u4 armhf [Installiert,automatisch]
apache2-data/stable,now 2.4.38-3+deb10u4 all [Installiert,automatisch]
apache2-utils/stable,now 2.4.38-3+deb10u4 armhf [Installiert,automatisch]
apache2/stable,now 2.4.38-3+deb10u4 armhf [installiert]
php-common/stable,now 2:69 all [Installiert,automatisch]
php-curl/stable,now 2:7.3+69 all [installiert]
php-gd/stable,now 2:7.3+69 all [installiert]
php-intl/stable,now 2:7.3+69 all [installiert]
php-mbstring/stable,now 2:7.3+69 all [installiert]
php-mysql/stable,now 2:7.3+69 all [installiert]
php-xml/stable,now 2:7.3+69 all [installiert]
php7.3-cli/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-common/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-curl/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-gd/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-intl/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-json/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-mbstring/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-mysql/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-opcache/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-readline/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]
php7.3-xml/stable,now 7.3.19-1~deb10u1 armhf [Installiert,automatisch]

I did some more investigation: The affected server has no TLS activated (http only). On another server (this time TLS enforced and also reachable from the internet) I have absolutely no problem installing the VisualEditor.
I have no other instance I could use for further testing which setting exactly causes the VisualEditor on the first instance to fail.

Even more investigation: I found out that the working server had more php-packages installed. After installing them on the first one VisualEditor is running :) The necessary must be among them:
sudo apt install php-bz2 php-pear php-zip php-bcmath php-gmp php-pspell php-tidy

I have no clue which one was the missing one, but that should be pointed out in the install documentation.

Running on a server with all libs installed Chris was mentioning, we still run into the 500 errors. The weird thing is, this seems to be a native editor issue - not a misconfigured parsoid instance.

While VE set as the default editor and trying to edit an existing page, we run into a 500 error with "Error contacting the Parsoid/RESTBase server (HTTP 500)". This is without any prerequierments or limitations in regards to text or code length of the particular site in question.

Vice-versa, when trying to CREATE a site, the VE works flawlessly and saves without errors. Trying to edit the very same newly created page, we run into the error 500 again. So my best guess is, that the implementation for the edit functions doesn´t work as an isolated error.

TiuriElensar triaged this task as High priority.EditedMar 26 2021, 9:55 AM

All those Wikis with not very tech-savyy users or webmasters, or sitting on servers without root access and/or are using a one-click-install instance of MW - in mind , I feel it appropriate that the priority of this issue has to be escalated, so those wikis are operational even for those (which will cover the majority of all wikis out there, run by private individuals).

Please note also, that hosters providing customers with one-click-applications by now only provide the last major second point releases, i.e. 1.35.0 - but not subsequent releases like 1.35.01. Providing a hotfix wold be appreciated and an inclusion into the 1.35.0 repository is needed.

Does this URL work on your wiki: when you replace:

  • with your wiki domain name,
  • Main_Page with your wiki main page (possibly different if your language is not English or if you customised it),
  • 12 with the revision ID of your main page (you can find it on the main page > toolbox (“Tools” section) > link “Permanent link”, it is the parameter oldid in the URL).

The VisualEditor is internally calling this page, so if this is not working the whole VisualEditor cannot work.

If this URL does not work, make sure:

  • the Apache configuration allows to call the file rest.php (this file is quite new, and really used since 1.35),
  • you have something like AllowEncodedSlashes NoDecode in your Apache config, at least for the wiki domain (see VE documentation).

Hello Seb,

regarding the given task, the answer is no, the link doesn´t work:

"The requested relative path (/ did not match any known handler"

My setting:
CentOS 7, PHP 7.4.16, FPM served by Apache, AllowEncodedSlashes NoDecode as domain directive and calls to rest.php are allowed by default.

Given your last error message, it seems the RestRoutes are not loaded, you can try to force them with the following line in LocalSettings.php:

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );

(although it should be automatically done with MW 1.35, at the contrary of MW 1.36.0-alpha (T266970))

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );

Would have been an easy fix, Seb, but unfortunal that´s a turn & burn. It still throws the error on edit, but works flawless on create.

To narrow the error down:
please can everyone confirm, that this error is isolated for EDITING existing pages and - vice-versa - the VE works flawlessly while CREATING and SAVING new pages without errors. At least this could exclude, that Parsoid isn´t invoked correctly via LocalSettings.php .

With the narrowing create=working/exiting=non-working, I remind others had this issue. I found T263928, D3nnis3n had this issue (warning: on the mentionned issue, a lot of people had similar-but-not-exactly-the-same issues and it is difficult to follow, so strictly read D3nnis3n). If I understand correctly, he fixed it using nginx. But perhaps you can try this: T263928#6528000 (the mentionned 403 issue is perhaps/probably because of cookies in a private wiki).

Generally speaking, these issues lies on the webserver config, so strictly check the rewrite rules to be sure 1/ the rest.php is correctly called, 2/ correctly retrieve the PATH_INFO, 3/ (minor) correctly interpret the slashes encoding (else titles with slashes could not work in the VisualEditor). Also be sure your DNS domain name is internally resolved (given there are internal HTTP calls).

If you need more help, you should publish relevant logs (Apache error logs), specific Apache config (all Apache config: general + htaccess) + MW config you have (wgVirtualRestConfig, wgServer, VisualEditor/Parsoid relevant config) so that I (or others) can reproduce the environement.

Hey Folks,

If the following issue should be an separate bug report, please tell me!

I want to chip in because I am encountering the some related problem with HTTP 500 when trying to edit on Supages of Pages.
We have a Mediawiki 1.35.2 running and I installed the VisualEditor Extension.'
Info: I have deactivated the extension in the meantime, for testing purposes I can enable it again if you are interested to test it.

At first I encounted the HTTP 404 Error which I fixed with the Apache Config from this post:

Afterwards HTTP 500 Error happened and I could trace it to the cause.
Scenario: You edit at Subpage of a page. Real Example:

Following request happens from Mediawiki:


image.png (27×1 px, 9 KB)

In the browser:

image.png (488×1 px, 122 KB)

with URL encoding decoded:

image.png (283×1 px, 39 KB)

When I read your post Seb35 ( I understood the naming scheme of the endpoint.

While fiddeling with the endpoint according to the seen HTTP Request in the screen above I realised that the Parsoid Endpoint is broken or at least have a totally strange behavior:

So I encountered at minimum 3 different behaviors on that endpoint:

  1. if you just call it with a existing top page (Example it will redirect to the latest revision ->
  1. if you just call it with a existing top page with some random existing revision of any page (Example - revision is of this page: ) it will show you the HTML Rendering of that Page, whose revision you used.

image.png (425×1 px, 86 KB)

  1. When calling a subpage, it will ignore it and just show the parent page:

Parent Wiki Page:
Child Wiki Page:
Api Parentpage:
Api Child Page:

Both will show the following:

image.png (300×995 px, 36 KB)

but have as site title the WikiPage in the URL.

This also shows the problem , when subpages have just numbers:

Calling those page on the API will be interpreted as revision 2020 in the api logic:

image.png (426×977 px, 101 KB)

Hope that helps,

With the narrowing create=working/exiting=non-working, I remind others had this issue. I found T263928, D3nnis3n had this issue (warning: on the mentionned issue, a lot of people had similar-but-not-exactly-the-same issues and it is difficult to follow, so strictly read D3nnis3n). If I understand correctly, he fixed it using nginx. But perhaps you can try this: T263928#6528000 (the mentionned 403 issue is perhaps/probably because of cookies in a private wiki).

I have had the same problem on 3 different wikis on 2 servers. On server 1 creating pages by VE worked, editing failed with 500. On server 2 no problems with 1.35.

It seems that both servers have different write rights for /tmp.

Changing $wgTmpDirectory to "$IP . '/images/temp';" solved the issue. To be honest as I am not a Linux guru I don't know if this has any sideeffects.

Edit: now I found T268420 which seems to be the problem on my fresh installations: A shared server and I have no idea how many wiki by other customere are hosted there.

I'm running MW 1.35 from the Debian Bullseye repository and I was getting the "Error contacting the Parsoid/RESTBase server (HTTP 500)" error. None of the suggestions above worked for me. However, I found that changing line 26 of
/usr/share/mediawiki/vendor/wikimedia/parsoid/src/Wt2Html/Grammar.php from

class Grammar extends \WikiPEG\PEGParserBase {


class Grammar extends \Wikimedia\WikiPEG\PEGParserBase {

fixed the error.