Last modified: 2009-05-26 06:03:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10733 - api.php can return an "wikimedia foundation error" html page
api.php can return an "wikimedia foundation error" html page
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.11.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 13762 18920 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-28 23:23 UTC by CBM
Modified: 2009-05-26 06:03 UTC (History)
7 users (show)

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


Attachments

Description CBM 2007-07-28 23:23:19 UTC
It is possible for api.php to return the "wikimedia foundation error" HTML page.  This appears to be a transient error. The api should return an xml error message (or better, follow the format= parameter) instead of the html error page. Adding another possible format for output makes it much more difficult to write reliable code for the api.
Comment 1 Yuri Astrakhan 2007-07-29 04:48:50 UTC
What is the request you were making? Also, please attach the html of that page. Api should handle all internal exceptions already, so this will help track it down.
Comment 2 CBM 2007-07-29 11:47:38 UTC
I was fetching user contributions. The URL was of the form 

  en.wikipedia.org/w/api.php&action=query&list=usercontribs&uclimit=1000&ucstart=...&ucuser=...

Of course I had to be logged in to do this. I didn't keep a copy of the HTML; if I see the error again, 
I'll attach it. 
Comment 3 Rob Church 2007-07-29 13:46:01 UTC
This sounds like an error coming from Squid, which would be above the control of MediaWiki. There *ought* to be appropriate response codes being set, however.
Comment 4 CBM 2007-08-21 02:17:44 UTC
Finally I have some details on this. The HTTP error code returned is 502 as Rob Church said. The error page includes the following:
  Request: POST http://en.wikipedia.org/w/api.php, from 66.230.200.132 via sq22.wikimedia.org
  (squid/2.6.STABLE12) to 10.0.5.3 (10.0.5.3)<br/>
  Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 21 Aug 2007 01:58:06 GMT
To get this, I put a lot of load on the usercontribs query. 

I can get the same error (HTTP 502)
  Request: POST http://en.wikipedia.org/w/api.php, from 66.230.200.137 via sq22.wikimedia.org 
  (squid/2.6.STABLE12) to 10.0.5.3 (10.0.5.3)<br/>
  Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 21 Aug 2007 02:06:11 GMT
by using the action=allusers query to list sysops on enwiki.

The ideal behavior (for me) would be an XML error message with HTTP code 404 instead of HTTP code 502. 
This would agree with the API docs "For now we decided to include error information inside the same structured output as normal result (option #2)." and "All output will be available in a structured tree format such as XML, JSON, YAML, WDDX, or PHP serialized."

I appreciate the 502 status return is likely the intended current behavior of the squids, but perhaps they could return a generic XML error page if they notice the query was for the API. 
Comment 5 Roan Kattouw 2007-08-21 09:30:24 UTC
This is very weird, why is Squid even attempting to cache api.php results? Shouldn't the API implementation tell Squid its output is non-cacheable?

(In reply to comment #4)
> The ideal behavior (for me) would be an XML error message with HTTP code 404
> instead of HTTP code 502. 
> This would agree with the API docs "For now we decided to include error
> information inside the same structured output as normal result (option #2)."
> and "All output will be available in a structured tree format such as XML,
> JSON, YAML, WDDX, or PHP serialized."
> 
> I appreciate the 502 status return is likely the intended current behavior of
> the squids, but perhaps they could return a generic XML error page if they
> notice the query was for the API. 
> 

The XML error page thing is expected behavior for all API modules, and works for most of them. I personally disagree that a 404 error code should be specified, however: that would mean api.php doesn't exist. In my opinion, we shouldn't mess with HTTP response codes and return any errors in the XML output.
Comment 6 Daniel Kinzler 2007-08-21 09:48:02 UTC
@Comment #4: As Rob said, the error is not comming from api.php, or MediaWiki at all. Your request is going through a Squid proxy, which is trying to forward it. If the forward fails, you get an error page from the squid, with an appropriate error code. For Errors on the HTTP level, you can not expect XML error messages. In fact, you can't expect anything beyond the correct HTTP error code. So, always check the error code - and ideally also always check the Content-Type reported from the server. For some error codes, the response *might* be generated by api.php, and *might* be in XML format. But you cannot rely on that, HTTP errors can happen before any PHP code is ever executed. This is true for all HTTP based APIs, including all REST and AJAX stuff, SOAP, etc.

@Comment #5: Squid is not trying to cache the response from api.php, but to forward the request to api.php. All HTTP requests to wikimedia sites go through the Squids. After all, they don't only do caching, but also load balancing. And your browser couldn't know in advance which pages to request from squid and which not, and where from instead, anyway: it simply gets the Squid's IP address when resolving the host name, and consequently sends all requests to the squid. Which is the point of Squids, really.

Closing as invalid, since this behavior is imposed by using HTTP transport, and complient with the HTTP spec.
Comment 7 Brion Vibber 2008-04-16 19:06:16 UTC
*** Bug 13762 has been marked as a duplicate of this bug. ***
Comment 8 Roan Kattouw 2009-05-26 06:03:26 UTC
*** Bug 18920 has been marked as a duplicate of this bug. ***

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


Navigation
Links