This works fine:
However, the same query via POST, signed with OAuth, results in:
Internal Server Error
Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.
This always worked fine, until around 2014-10-22. It appears to coincide with the new, shiny API pages.
Version: unspecified
Severity: major
Update: This seems to happen on some but not all attempts. Maybe some servers behave differently?
Update 2: One query returned me being OAuth-enticated as an IP. Specifically, 10.68.17.9, which wasn't my IP at the time.
Change 168193 had a related patch set uploaded by Anomie:
API: Include ApiMain construction in api.php try-catch block
Cannot reproduce as described, submitting that query data to www.wikidata.org as a POST using OAuth with valid authorization headers works fine when I try it.
I do see exceptions logged about invalid authorization headers, and testing that does give an internal server error rather than the expected API error response. I'm going to go ahead and fix that error, and if you can confirm that it's only invalid authorization headers giving the problem then this bug can be changed back to PATCH_TO_REVIEW.
(In reply to Magnus Manske from comment #2)
Update 2: One query returned me being OAuth-enticated as an IP.
Specifically, 10.68.17.9, which wasn't my IP at the time.
10.68.17.9 is one of the Tool Labs webgrid hosts. Was the API query sent from Tool Labs?
That sounds like you hit a wiki using HHVM when the OAuth authorization was done using Zend, or vice versa. For some reason the OAuth stuff doesn't seem to be shared between the two.
(In reply to Brad Jorsch from comment #4)
Cannot reproduce as described, submitting that query data to
www.wikidata.org as a POST using OAuth with valid authorization headers
works fine when I try it.
It's on-and-off, and seems to go away when I renew the OAUth permissions, at least for a while.
Try a browser where you haven't used my Widar OAuth "proxy tool" (if ever). This URL
http://tools.wmflabs.org/widar/index.php?action=get_rights&botmode=1&test=1
should show the "Internal server error" while the problem persists, reproducibly. May serve you for testing the patch.
I do see exceptions logged about invalid authorization headers, and testing
that does give an internal server error rather than the expected API error
response. I'm going to go ahead and fix that error, and if you can confirm
that it's only invalid authorization headers giving the problem then this
bug can be changed back to PATCH_TO_REVIEW.(In reply to Magnus Manske from comment #2)
Update 2: One query returned me being OAuth-enticated as an IP.
Specifically, 10.68.17.9, which wasn't my IP at the time.10.68.17.9 is one of the Tool Labs webgrid hosts. Was the API query sent
from Tool Labs?
Yes, the Widar tool.
That sounds like you hit a wiki using HHVM when the OAuth authorization was
done using Zend, or vice versa. For some reason the OAuth stuff doesn't seem
to be shared between the two.
Well, that should go away once they are all using HHVM, right?
Change 168193 merged by jenkins-bot:
API: Include ApiMain construction in api.php try-catch block
Change 168296 had a related patch set uploaded by Anomie:
API: Include ApiMain construction in api.php try-catch block
(In reply to Magnus Manske from comment #5)
Try a browser where you haven't used my Widar OAuth "proxy tool" (if ever).
This URLhttp://tools.wmflabs.org/widar/index.php?action=get_rights&botmode=1&test=1
should show the "Internal server error" while the problem persists,
reproducibly. May serve you for testing the patch.
That'll test the "invalid oauth header" case, yes. The outstanding question is whether that's the sole cause of what you're seeing.
Since the patch for the known issue is in the process of being merged and I'll backport it during the SWAT window that starts in about 15 minutes, the easiest way to answer that is probably to wait an hour and then see if you can still reproduce the failure.
That sounds like you hit a wiki using HHVM when the OAuth authorization was
done using Zend, or vice versa. For some reason the OAuth stuff doesn't seem
to be shared between the two.Well, that should go away once they are all using HHVM, right?
Yes.
I have tried quite a few times now, and never got the Internal Server Error, nor did I get an IP-as-a-name. Everything looks like it should!
(In reply to Magnus Manske from comment #9)
I have tried quite a few times now, and never got the Internal Server Error,
nor did I get an IP-as-a-name. Everything looks like it should!
That's interesting, because I haven't merged the backport yet...
Change 168296 merged by jenkins-bot:
API: Include ApiMain construction in api.php try-catch block
Now it's merged, and the test link from comment 5 is reporting an API error rather than Internal Server Error. Feel free to close this as RESOLVED FIXED if you can't reproduce anymore.
Reopened this; API seems to function now, but I get occasional, non-reproducible "bad token" or not-authorized errors. I /think/ I tracked it down to an issue mentioned in the above thread: sometimes, my OAuth user name comes back as 10.68.16.28.
It's annoying (batch process interrupts), but not really essential. Please close the bug again if you think it will solve itself soon (HHVM or the like).
Since this issue was about the "Internal Server Error" rather than an API error response, let's keep this closed unless that's recurring.
If you want to open a new bug about OAuth not being logged in between Zend and HHVM, feel free. BTW, it appears you can check whether it was Zend or HHVM by looking at the HTTP headers: "X-Analytics" seems to be either "php=zend" or "php=hhvm".