If you put a large query into WDQS GUI, it would produce 414 Request-URI Too Large since URI size is limited. However, WDQS supports also POST queries now, so instead the GUI should switch to POST from GET when certain threshold (probably should be configurable) has been passed.
Description
Details
Related Objects
Event Timeline
This was implemented long ago (apparently without a Phabricator task, but see Ic770e25bb4 and Ic3ea53c50e), but I guess something is behaving differently now? I don’t recall seeing an HTTP 414 error back then, the request just wouldn’t be sent at all (client-side limit).
I see the code is:
if ( request.getAllResponseHeaders() === '' ) { // query might have been too long for GET, retry with POST settings.method = 'POST'; $.ajax( self._serviceUri, settings ).done( done ).fail( fail ); }
I suspect when the server rejects it, the headers are not empty. It also can be a proxy on the way rejecting it, of course.
Yeah, the existing code only detects when the browser doesn’t send a request at all, so I guess there must now be some length that the browser still sends but the server rejects.
This would of course be easier to debug if the reporting user on Wikidata provided the failing query :/
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
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:
Reason:
superceded