Last modified: 2013-04-22 16:17:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43042, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41042 - Requesting 'sections' for nonexistent page does not give error
Requesting 'sections' for nonexistent page does not give error
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-15 18:04 UTC by Brian McNeil
Modified: 2013-04-22 16:17 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brian McNeil 2012-10-15 18:04:20 UTC
I'm writing a set of PHP classes to replace botclasses.php for automated use of the API. I've come across what I feel is a bug, but the API does not return an error for it.

If I request the sections (TOC) for "Does-not-exist", I get an 'empty' result. If I request the sections (TOC) for "Special:Does-not-exist", I get a real error thrown.

This means I've had to code my function such that when an empty list of sections is returned, it checks if the page exists, thus:

        $q  = '&prop=sections&page='.urlencode($page);
        if ( $revid !== null )
            $q  .= '&rvstartid='.$revid;

        $r  = $this->query_content( $q );
        if ( isset($r['error']) ) { // Error getting any page data
            return self::ERR_ret( self::ERR_error, "API error, info:"
                .$result['error']['info']." Result:".$result['error']['code'] );
        }
        $toc_elem   = $r['parse']['sections'];
        if ( empty($toc_elem) ) { // Empty, does that mean page doesn't exist?
            if ( $this->get_page( $page ) == false) {
                return self::ERR_ret( self::ERR_warn, "Requested TOC for nonexistent page" );
            }
        }

Because the API is not returning an error straight away that indicates the page does not exist, a second API call is needed to pull the entire page or throw an error because a nonexistent page was requested.

This can be seen with
http://en.wikinews.org/w/api.php?action=parse&format=xml&prop=sections&page=doesnotexist
versus
http://en.wikinews.org/w/api.php?action=parse&format=xml&prop=sections&page=Special:doesnotexist

Only the latter throws an error.
Comment 1 Dereckson 2012-10-15 21:37:39 UTC
The error returned by an API call against a special page doesn't mean the page doesn't exist but you can't create a WikiPage object from some namespaces (in default install, media and special).

If you read the http://en.wikinews.org/w/api.php?action=parse&format=xml&prop=sections&page=Special:doesnotexist error text, you'll see:

<error code="internal_api_error_MWException" info="Exception Caught: Invalid or virtual namespace -1 given." xml:space="preserve"/>

This is an exception thrown by WikiPage::Factory method.

Note the same error will be thrown by API calls requesting sections from *existing* special pages:
https://en.wikinews.org/w/api.php?action=parse&format=xml&prop=sections&page=Special:Version
Comment 2 Amgine 2012-10-15 21:40:03 UTC
(In reply to comment #1)
> The error returned by an API call against a special page doesn't mean the page
> doesn't exist but you can't create a WikiPage object from some namespaces (in
> default install, media and special).

The point, Dereckson, is that no error is returned by API action=parse when a page does not exist, despite documentation stating it will.
Comment 3 Dereckson 2012-10-15 21:46:25 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > The error returned by an API call against a special page doesn't mean the page
> > doesn't exist but you can't create a WikiPage object from some namespaces (in
> > default install, media and special).
> 
> The point, Dereckson, is that no error is returned by API action=parse when a
> page does not exist, despite documentation stating it will.

My comment explains why there is a difference between the two API calls and to stress on the fact the error returned by the second API call weren't related to the page non existence. This helps to clarify the bug and allows to focus on to the point you've just stressed.
Comment 4 Brad Jorsch 2012-10-16 12:23:12 UTC
(In reply to comment #2)
> 
> The point, Dereckson, is that no error is returned by API action=parse when a
> page does not exist, despite documentation stating it will.

Where does the documentation state this? The only thing I see at [[mw:API:Parsing wikitext#parse]] that is even close is a note that an error will be returned for an ''invalid'' title. Or are we referring to the misleading message quoted for the "missingtitle" error?

It seems to me that a page that does not exist has no sections, so the returned result is technically correct. As noted above, Special-namespace pages cannot be parsed at all.

Note you can check if the page existed by including 'revid' in the props and checking for 0, e.g. https://en.wikinews.org/w/api.php?action=parse&format=xml&prop=sections|revid&page=doesnotexist. This is noted in the documentation at [[mw:API:Parsing wikitext#parse]].
Comment 5 Amgine 2012-10-16 15:02:13 UTC
I interpreted

* code: missingtitle
** info: The page you specified doesn't exist.

from https://www.mediawiki.org/wiki/API:Parsing_wikitext#Possible_errors_2 as not at all misleading, but directly and simply stating an error is generated when a page specified does not exist. The same language is used at https://www.mediawiki.org/wiki/API:Parse#Errors_Codes, and it is listed as a standard error at https://www.mediawiki.org/wiki/API:Errors_and_warnings#Standard_error_messages. This would be the least surprising interpretation, in my opinion.

It is *not* the same behavior as API displays in some other actions, however. In &action=query a missing page is simply reported as missing, not an error code.

https://en.wikinews.org/w/api.php?action=query&titles=DoesntExist&prop=info&format=xml

According to [[mw:API:Errors_and_warnings]]

"If something goes wrong in an API request, an error or a warning will be thrown. Warnings are thrown for non-fatal conditions such as invalid parameters, whereas errors are only thrown for fatal conditions."

My personal opinion is there should be an explicit report for both no sections && missing page; the former should throw a warning (setting sections property count=0), the latter might throw either a warning (setting page property missing=';') or an error. A section count property could resolve the former as an enhancement.
Comment 6 Brad Jorsch 2012-10-16 15:55:35 UTC
I've reviewed the matter, and it seems that the behavior here has recently changed accidentally due to Gerrit change #18973. I've submitted Gerrit change #28225 to revert to the old behavior.
Comment 7 MZMcBride 2012-10-16 22:23:02 UTC
(In reply to comment #6)
> I've reviewed the matter, and it seems that the behavior here has recently
> changed accidentally due to Gerrit change #18973. I've submitted Gerrit change
> #28225 to revert to the old behavior.

Does the API support PHP unit tests? If so, I think it would be nice to add a test for this to prevent this from happening in the future, if possible.
Comment 8 Umherirrender 2012-10-19 16:29:54 UTC
You can use http://en.wikipedia.org/w/api.php?action=query&titles=Not%20Exist|In%7Bvlid|Special:Not-exist to validate one or more titles with the api.

You will get:

<?xml version="1.0"?>
<api>
  <query>
    <pages>
      <page ns="0" title="Not Exist" missing="" />
      <page title="In{vlid" invalid="" />
      <page ns="-1" title="Special:Not-exist" special="" missing="" />
    </pages>
  </query>
</api>

Special pages also supported and some more stuff (like converting of titles and redirects)
Comment 9 Derk-Jan Hartman 2012-10-30 19:53:22 UTC
The change was merged, marking as fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links