Page MenuHomePhabricator

Queries of a certain size-range produce errors in Wikidata Query Service GUI
Closed, ResolvedPublic


Largish (but not too large) queries are failing with URI/header "too large" errors when using the interface at

Browser/OS: Chrome 72 and Firefox 65 on Windows 10.

<h1>Bad Message 431</h1><pre>reason: Request Header Fields Too Large</pre>
<head><title>414 Request-URI Too Large</title></head>
<body bgcolor="white">
<center><h1>414 Request-URI Too Large</h1></center>

Once the query grows sufficiently large it works fine again: example

I first noticed this around the 9th of January (2019) and posted here:
As that post states, I had an unchanged query that was working only a couple of days before that.

Technically, I believe that those errors arise due to the limits on GET requests, as noted in the manual. But if you look at the working example with the network tab open in your browser devtools, the GUI can transparently switch/fallback to making a POST request.

Looking at the code repo for the client, the frontend logic that controls this fallback doesn't seem to have changed anytime recently, so my assumption is that there has been some sort of server upgrade or configuration change that changed how it responds when it fails. I'm guessing the frontend needs to be changed to account for that.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 20 2019, 5:20 AM

Also I might as well add here that clicking on the "Help" dropdown > "Give Feedback!" goes to (notice lower case) which doesn't post to the real page at Talk:Wikidata_Query_Service. There is a redirect set up, but the "new section" page doesn't respect that.

NoInkling updated the task description. (Show Details)Feb 20 2019, 5:39 AM

Whoops, this seems to be a dupe of T213889. Still, I hope the extra info is useful.

NoInkling added a comment.EditedFeb 20 2019, 6:54 AM

By modifying the code using browser local overrides, I can confirm that doing the equivalent (since it's minified) of changing the condition to the following works:

if ( request.getAllResponseHeaders() === '' || request.status === 414 || request.status === 431 ) {

@NoInkling since it sounds like you have the code already figured out, would you like to submit a Gerrit change? (I could also do it, but I would kinda feel like I’m stealing your work ^^ )

@Lucas_Werkmeister_WMDE I can do it, but I didn't really want to go through the trouble of opening a developer account and going through the whole Gerrit setup and learning the workflow just for one change. Plus I'm not sure if it also requires regression tests. So you have my permission (it's only a tiny change anyway), otherwise I'll try and get around to it when I'm able.

Change 494282 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[wikidata/query/gui@master] Retry queries with POST if server indicates request was too large

Bizarrely, I can only reproduce the 414 Request URI Too Large error (example 2) in Chromium, in Firefox that one still works with GET o_O

Anyways, patch is up, thank you!

Change 494282 merged by jenkins-bot:
[wikidata/query/gui@master] Retry queries with POST if server indicates request was too large

Change 494376 had a related patch set uploaded (by WDQSGuiBuilder; owner: WDQSGuiBuilder):
[wikidata/query/gui-deploy@production] Merging from e9f3dd43523caa0878ca01f21b1e431c0b4b70be:

Change 494376 abandoned by Smalyshev:
Merging from e9f3dd43523caa0878ca01f21b1e431c0b4b70be:


Hm, there was a Wikidata Query Service weekly deploy window earlier today, but I can still reproduce the bug… @Mathew.onipe did you update the query service UI?

Lucas_Werkmeister_WMDE closed this task as Resolved.Apr 12 2019, 10:00 AM
Lucas_Werkmeister_WMDE claimed this task.

Okay, this seems to be fixed now.