Bugs item #1898707, was opened at 2008-02-21 07:36 Message generated for change (Comment added) made by russblau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1898707...

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dashiva (magnusrk) Assigned to: Nobody/Anonymous (nobody) Summary: Infinity loop on missing api.php

Initial Comment: If api.php isn't at the default /w/api.php, or apipath() is defined but gives the wrong value, the bot keeps requesting the page over and over with no notification to the user.

Eventually python reaches the maximum recursion depth, throws, and the script stops a minute before starting again. At each pause it prints a warning saying it couldn't find <url>, but none of the warnings appeared until I stopped the script with ctrl-c (might be windows/py2.4 specific).

I think the best solution would be to distinguish between "Could not load api.php" and "Successfully loaded some page, but it doesn't look like api.php". In the latter case, there isn't much to gain from trying over and over.

(Off topic: How about a scriptpath() for setting path/querypath/apipath all in one? They're usually in the same directory.)

----------------------------------------------------------------------

Comment By: Russell Blau (russblau)

Date: 2008-02-21 12:01

Message: Logged In: YES user_id=855050 Originator: NO

This is not so easy to fix, because it is grafting a bit of api.php onto a framework that was designed to use index.php. It may mean that bots will no longer work at all on wikis using older, pre-api.php versions of MediaWiki.

A possible approach might be to use postForm() instead of getUrl() to retrieve the api.php data; postForm will return an HTTP response object that can be checked for 404 and other error codes, whereas getUrl just returns a string which may or may not be meaningful.

In the meantime, I will implement the scriptpath() suggestion, but that will require that users hand-fix family files for every wiki that doesn't use the default 'w/' prefix, and also won't fix the backwards-compatibility problem mentioned above.

----------------------------------------------------------------------

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1898707...