Last modified: 2012-10-26 21:30:39 UTC
I created a blank page at <https://www.mediawiki.org/wiki/VisualEditor:Hello_there>. When I try to edit the page using the VisualEditor extension, I receive the following error: "Error loading data from server: No HTML content in response from server. Would you like to retry?" I imagine this is a safety check somewhere in the code that needs to be tweaked. If page_len == 0, it isn't always an error. Sometimes a blank page is just a blank page. ;-)
That blank page shouldn't have been possible to create in the first place.
(In reply to comment #1) > That blank page shouldn't have been possible to create in the first place. Heh, well I originally created the page as the brand new account I was using to test VisualEditor didn't have the createpage right (for whatever reason). To be clear, this bug is not about VisualEditor creating a blank page. This bug is about VisualEditor throwing an error when the page length is 0 bytes and the user attempts to edit the page using the VisualEditor interface. <https://www.mediawiki.org/wiki/VisualEditor:Blank_page> is another test case. For discussion regarding whether MediaWiki should allow users to create blank pages, you want bug 12621. :-)
Mass-moving items into VisualEditor product
Parsoid does handle zero length content -- it returns a zero length HTML response. Right now, VisualEditor extension expects a non-zero HTML response and returns an error if not (line 18 of ApiVisualEditor.php). This can be verified at this url: https://www.mediawiki.org/w/api.php?action=ve-parsoid&paction=parse&page=VisualEditor%3AHello_there&format=json (for other pages, the result is success with a valid parsed string). So, either ApiVisualEditor.php has to handle a zero-length response as a valid response, and we need a different way to signal errors from Parsoid, or Parsoid has to always return a non-zero response. My hunch is that as long as Parsoid returns a 200 OK, ApiVisualEditor accept a zero-length response as a valid response (and if necessary, have sanity checks somewhere -- a non-zero length body should not return a zero-length response, maybe). Error conditions from Parsoid could be signaled with a different HTTP response code maybe (offhand, 503 is one option). At this time, I am not sure what the right solution is, but hopefully this will help figure out what that might be.
Actually, I meant 500, not 503.
Moving to DM if we're happy with current Parsoid behaviour - to discuss?
(In reply to comment #1) > That blank page shouldn't have been possible to create in the first place. You can easily create a blank page by first creating a page with content, then blanking it. (In reply to comment #4) > Parsoid does handle zero length content -- it returns a zero length HTML > response. Right now, VisualEditor extension expects a non-zero HTML response > and returns an error if not (line 18 of ApiVisualEditor.php). This can be > verified at this url: > https://www.mediawiki.org/w/api.php?action=ve-parsoid&paction=parse&page=VisualEditor%3AHello_there&format=json > (for other pages, the result is success with a valid parsed string). Thanks Subbu, that's exactly what was going on. Fix submitted in https://gerrit.wikimedia.org/r/30281 . > So, > either ApiVisualEditor.php has to handle a zero-length response as a valid > response, and we need a different way to signal errors from Parsoid, or Parsoid > has to always return a non-zero response. My hunch is that as long as Parsoid > returns a 200 OK, ApiVisualEditor accept a zero-length response as a valid > response (and if necessary, have sanity checks somewhere -- a non-zero length > body should not return a zero-length response, maybe). Error conditions from > Parsoid could be signaled with a different HTTP response code maybe (offhand, > 503 is one option). At this time, I am not sure what the right solution is, but > hopefully this will help figure out what that might be. I verified that nonexistent pages give me a 404, so I think this is fine. I haven't checked other error conditions because they're nontrivial to reproduce, but as long as Parsoid only returns a 2xx status code when it's actually delivering parsed content and uses 4xx/5xx for errors, I'll be fine.
Resolved in gerrit. Change-Id: I8857d39e1a20080c8419c6165be2b5ad0cdbacd2
