Page MenuHomePhabricator

Occasional "docserver-http: HTTP 404" when trying to save an edit made in the visual editor
Closed, ResolvedPublic1 Estimated Story Points


When I update a page sometimes it's impossible to save the edit. I get the following error message: docserver-http: HTTP 404

It doesn't happen all the time I try to save, but only for certain pages.
The error happens when I press the save button after the dialogue where I can add a summary. When I press the close button ("Sluiten") I return to the dialogue to add a summary, but with the save button greyed out. It's also impossible to check the edits I made ("wijzigingen controleren") that also returns error 404. Trying to switch to source editing keeps hanging and never switches to source mode.
Example page where this happend:

This was later attributed to interaction with local code. Thoughts and fixes are provided toward the end of the page.

Event Timeline

Mbch331 raised the priority of this task from to Needs Triage.
Mbch331 updated the task description. (Show Details)
Mbch331 added a project: VisualEditor.
Mbch331 added a subscriber: Mbch331.
Aklapper renamed this task from Error 404 when trying to save an edit made in Visual Editor to "docserver-http: HTTP 404" when trying to save an edit made in Visual Editor.Jan 15 2016, 3:36 PM
Aklapper set Security to None.

Problem still exists, rather annoying when you do multiple updates on a page and then need to switch to text editor and redo the edits.

Jdforrester-WMF renamed this task from "docserver-http: HTTP 404" when trying to save an edit made in Visual Editor to Occassional "docserver-http: HTTP 404" when trying to save an edit made in Visual Editor.Feb 2 2016, 8:11 PM
Jdforrester-WMF triaged this task as Medium priority.
Jdforrester-WMF edited a custom field.
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Do you have any particular reproduction steps? Do you think it's related to a particular account, set of pages, abuse filter or similar?

I usually use Visual Editor when I want to add an image to an infobox. So far it's pages with infoboxes, but it's hard to say what exactly is needed for it to happen. 8 out of 10 times I add a photo to an infobox this happens. Most of the time I also edit some other information in the infobox at the same time, when I notice information that's in an article isn't in the infobox or information is in the wrong place in an infobox. Could it help if I had time and page where it happens?

@Mbch331, every details is useful and welcome. Thanks.

Elitre renamed this task from Occassional "docserver-http: HTTP 404" when trying to save an edit made in Visual Editor to Occasional "docserver-http: HTTP 404" when trying to save an edit made in the visual editor.Feb 4 2016, 12:51 PM

Error occured February 2nd, 22:20 CET while trying to edit // I edited the infobox, added an image and corrected the field "geboorteplaats".

February 4th, 16:15 CET
Trying to add an infobox

February 4th, 21:20 CET'_Arrows
Trying to add image to infobox

February 5th, 20:51 CET
Trying to add DEFAULTSORT

February 10th 12:36 CET
Updated the infobox (added a picture and added some missing information)

I know these errors happen in the v.e., but I don't think it's its fault.

I have no idea where it happens, because I don't know what happens the moment you press save. I only know I notice this while using VE and never with the normal wikitext editor.

Another page where it happened:
14-02-2016 13:43 CET
I added a picture to the infobox.

3-3-2016 22:07 CET
Trying to add template commonscat to the article

Hi, I have the same problem. It occurs on every page I wat to edit, no matter where (so not just infoboxes). I work on a Mac OSX Yosemite with both Safari as a well as Chrome. And it occurs with both browsers.

@Mbch331 could you please try to edit:

  • a page whose name/title contains no special characters or spaces (only a-z and 0-9)
  • the text of the page itself, not infoboxes or other templates

Experimenting with combinations of the two criteria is gladly appreciated as well (edit an infobox on a page with no special characters, and editing a page's text on a page containing them). This will help us locate where the problem is, because currently I, for one, cannot tell if the problem is in VE, the back-end or somewhere in-between the two.

mobrovac raised the priority of this task from Medium to High.Mar 7 2016, 7:01 PM

Did a few tests (times are all in CET):
Minor text changes
no error message
Edited infobox
docserver-http: HTTP 404
Minor text changes
docserver-http: HTTP 404
Edited infobox
no error message

Thank you @Mbch331. I made a few tests myself on but couldn't reproduce it. I would say it is a VE back-end instability of some kind.

@Mbch331 after you get the message, are you able to save your changes? Try cancelling the dialogue, adding and then removing a space and saving again.

I just redid the change for, because I hadn't done that one in the wikitext editor. So that even makes it hard to reproduce. I know just cancelling the dialogue and re-try to save doesn't work, that gives the same error message. Can't switch to wikitext editor while keeping my changes, because the page gets stuck and the only thing that works is pressing the refresh button of my browser. Switching to wikitext editor without keeping the changes does work. Haven't tested it yet what happens if I make a dummy edit (adding and removing a space) after I get the error message (was planning on doing that to the Heineken Music Hall article, but the error didn't appear).

Also, @Mbch331, did you provide your OS/browser/skin details? (I can find @Brbbl ones, Mac OSX Yosemite with both Safari as a well as Chrome).

Just tested it with:
Got a doctype 404 error, while editing the infobox. I tried adding a space and removing it again. Didn't help. Switched to wikitext editor losing my changes. Immediately switch back to VE, did the same edit as before (adding genre to the infobox) and could save without problems.

I'm using Firefox on Windows 7 with Vector skin.

I repeated the last procedure of @Mbch331 and it worked for me as well. Switching from wikitext editor to VE without starting from VE also worked.
Edited the infobox, tried to save, got Doctype 404.
Cancelled save, tried show changes, popup: "server responded: 404"
Cancelled the save box, added a space, removed the space. Again doctype 404.
Checked page settings and corrected the defaultsort, tried to save. Again doctype 404.
Switched to wikitext editor without saving, edited part of the infobox and corrected the defaultsort, switched back to VE keeping changes, completed my edits to the infobox. Saved the page without problems.

So I noticed that once you're in VE and got the 404, you can't get rid of the 404 without loosing the changes and quitting VE.
Quitting VE and returning (by going to Wikitext editor) solves the problem, but you have to do the changes twice. Not all editors are willing to do this and thus we are loosing information (as most editors give up and in some cases even I will give up).

Just tested what happens when you refresh the page, then the problem is also solved (but also the changes are lost).

So currently the only way to get out of the doctype 404 error, is by leaving the current VE session with losing the changes.
That's no real solution.

This is really bad, and it's made worse because it's not clear what we can do to help. :-( The only thing I can think of that you'd get this (otherwise really rare) error so often is a browser plugin that is breaking your JS behaviour; possibly a "smart" security program that kills suspicious connections. Do you have any browser plugins or security software like that? Do you get the same behaviour in other browsers or on other computers, if you have them available?

Dear @Mbch331, it's not necessary to first go into VE > edit > change to Wikitext Editor and loose edits.
Starting in Wikitext Editor without making any changes and switch to VE immediately will let you edit and save changes in VE.

Actually, it's not possible since a few days to switch from VE to Wikitext editor. The option (button) to go to Wikitext editor with losing edits is gone.

I tried to edit with VE at home on my Mac OSX Yosemite with three different browsers, Chrome, Safari and Firefox. All off them gave me a 404. I turned off all extensions in Chrome (my default browser) but still a 404.

Now I try at work, again OSX Yosemite with Chrome...... again a 404.

I'll try to do it later on a PC.

@Brbbl Starting in Wikitext editor and than switching to VE is not a solution when someone starts in VE.

@Mbch331 Off course, it was meant to show that VE only seems to work after switching from Wikitext editor. So Wikitext editor triggers something that VE doesn't trigger at first. But this is not a workable way for inexperienced users. And that is what this VE was made for I guess.

This happens to me all the time using VE at WP NL, and its super demotivating as changes made are also not exportable.

Not sure what you mean by "not exportable", but would you mind offering specific examples of articles where this happened for sure recently to you, + info about your browser/operating system/skin? Thanks a lot.

well i cant save my edits in any meanignfull way so they're gone. I tried disabling all my firefox plugins but to no avail.

My headers are

POST /w/api.php HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Content-Length: 12049
Content-Type: multipart/form-data; boundary=---------------------------15516312635033135082098373395
forceHTTPS=true; centralauth_Session=a9a7cbf351625135d169de54912905af
Connection: keep-alive


HTTP/1.1 200 OK
Date: Tue, 03 May 2016 15:38:34 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 140
Server: mw1227.eqiad.wmnet
X-Powered-By: HHVM/3.12.1
x-content-type-options: nosniff
Cache-Control: private, must-revalidate, max-age=0
mediawiki-api-error: 404
X-Frame-Options: DENY
Content-Encoding: gzip
Vary: Accept-Encoding
backend-timing: D=61980 t=1462289914426984
X-Varnish: 2706765465, 1746685592, 951594181
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1065 pass+chfp(0), cp3040 pass+chfp(0), cp3033 frontend pass+chfp(0)
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
x-analytics: WMF-Last-Access=03-May-2016;https=1
x-client-ip: {redacted}
X-Firefox-Spdy: 3.1


{"servedby":"mw1227","error":{"code":"404","info":"docserver-http: HTTP 404","*":"See for API usage"}}

That'll be RESTBase erroring. Do you know what revision ID it's trying to base this on @Stratoprutser ?

Sorry I'm just a regular guy VE-user, no idea what you're talking 'bout.

I think Alex wants to know, which of the versions of the article were you trying to edit when the error occurred? (you did manage to edit it with VE multiple times that day.)

Alex, Slowking4 reports the same problem while trying to make this edit. Does this help?

hi, yes my screenshot was trying to edit this article insert > pages on the WS VE menu

would not change to wikitext editing, so lost edit first time

i repeated my steps and the edit succeeded

i was editing in wikitext and switching to VE, cannot replicate error, when saving wikitext editing and then invoking VE

Okay, if it now works for that revision ID there's not much I can do with it.

you can replicate the error

you can pick any WS page such as

delete the text in wikitext ; switch to VE; and attempt to insert > pages template
with page here

and log the result.

I also was able to reproduce this today on nl.wikipedia a bit too easily. I suspect it is the Zeusmodus gadget that is at fault, which is probably modifying the form on the page incorrectly or something.

On other wiki's it can be Zeusmode or another tool that carelessly modifies the edit page.

It's the 'hiddeneditform' that zeus loads into read mode of pages. If you enable the gadget, then visit a page, Zeus will automatically instantiate a 'hidden' edit page on each pageview (you can toggle it's visibility with the +/- at the bottom of the page). This then also ends up into the VE editor, which is somehow confusing it (not sure why exactly, could be the extra content, or it's resetting a token or timestamp field or something like that).

This also explains, why going to the Wikieditor first solves the problem, because you navigate to a different page, where the hiddeneditform is not loaded into the page, so you can start VE without the modifications made by Zeus.

edittoken: f144bc25a67cc7c12038a8cc11a3571c57d68567+\\
csrf token: f144bc25a67cc7c12038a8cc11a3571c57d68567+\\

Edit page retrieved by zeus

<input type='hidden' value="20160912103734" name="wpStarttime" />
<input type='hidden' value="20160912072151" name="wpEdittime" />
<input type='hidden' value="47439646" name="editRevId" />
edittoken: 826fe9f64965248905c5a01673f27c1057d6856e

VE init of info:

"basetimestamp": "20160912072151",
 "starttimestamp": "20160912103738",
 "oldid": 47439646

I can see that visualeditoredit, API call is made using the original edit token from the page, instead of the token that was later generated for the edit page that zeus loads. It thus seems likely that token errors are not handled appropriately at some point inside visualeditoredit, and that the token retry functionality of the api never gets a chance to kick in.

Is this still happening to people?

I don't know, but in case, looks like TheDJ may have found the culprit?

I just tried it again through my nl.wikipedia account. I still have the same problem.

@Esanders @DLynch @dchan Can we take a look at this and figure out whether it's an issue with VisualEditor like @TheDJ says it might be?

So, a quick skim of the Zeus mode gadget does suggest that it's doing something really messed up to the page with the edit form -- specifically, it's dumping the entire HTML of the edit page into its hidden div, including all the headers and scripts and whatnot. Since this includes various token-manipulation things, it wouldn't be surprising if this is causing problems. It's actually trying to not do this, but the method chosen was fragile and assumed the edit form markup would never change.

I'd fix it, but I don't have privileges to edit it.

That said, the problem is in:

There's a line 551:

a=xmlhttp.responseText.indexOf('<form id="editform"');

which should probably be:<form[^>]+id="editform"/);

(Because the form is now <form class="mw-editform-ooui" id="editform".)

This might, of course, be completely unrelated to the problem. But!

Oh, I should also say that in February I improved our refreshing of bad edittokens functionality (8a7d44224), which might also have helped randomly fix this.

@DLynch For the Zeusmode fix, just leave a message on Zanaq's talk page. He's still active on nlwiki, so he'll pick it up soon.

I'd fix it, but I don't have privileges to edit it.

That's fine since gadgets are community-owned. We're here to help and advise, which you did excellently. Thanks! :-)

Deskana assigned this task to DLynch.

So... is this resolved?

The change that @DLynch recommended was incorporated, so I assume so.

Jdforrester-WMF changed the point value for this task from 1 to 0.Oct 15 2017, 10:19 PM
Jdforrester-WMF changed the point value for this task from 0 to 1.