Another solution would be to automatically split up requests on the client if the get query is going to be too long. I prefer however the server config change option.

I think this should be detected during installation, right? Printing a warning then would be a good time to tell the person installing that they need to change things.

(In reply to comment #2)

I think this should be detected during installation, right? Printing a warning
then would be a good time to tell the person installing that they need to
change things.

Good idea.

Possible URL reduction method:

&modules=jquery:autoEllipsis,checkboxShiftClick,client,collapsibleTabs|jquery.ui:button,core,dialog

In addition to saving on module names, it also sends 1 byte for comma instead of 3 bytes for pipe which you have to percent-encode.

Note that an installation-time check isn't necessarily sufficient -- if your hosting provider changes their configuration later on, you won't be warned.

Max's suggestion at shortening the URLs by collapsing out common prefixes is quite clever, though dependency ordering may mean that doesn't always work in an optimized fashion. It also won't protect against a few more modules coming in and bumping it beyond the limit again...

(In reply to comment #5)

Note that an installation-time check isn't necessarily sufficient -- if your
hosting provider changes their configuration later on, you won't be warned.

Max's suggestion at shortening the URLs by collapsing out common prefixes is
quite clever, though dependency ordering may mean that doesn't always work in
an optimized fashion. It also won't protect against a few more modules coming
in and bumping it beyond the limit again...

Dependency ordering is irrelevant. The order of modules in the query string determines the order in which they are delivered, yes, but the client-side loader is smart enough to execute everything in the right order regardless of which order the delivery order.

(In reply to comment #6)

Dependency ordering is irrelevant. The order of modules in the query string
determines the order in which they are delivered, yes, but the client-side
loader is smart enough to execute everything in the right order regardless of
which order the delivery order.

Furthermore, the module list is always sorted before it's turnd into query string.

Note that an installation-time check isn't necessarily sufficient --
if your hosting provider changes their configuration later on, you
won't be warned.

Agreed. This really goes for almost all the warnings at installation.

Further, I like WordPress's admin interface that lets you know when an
update is available for WP itself or for one of the WP extensions. I
think some work has already been done in that way,

So, I probably need to file a new bug requesting this admin page
feature that would provide all sorts of warnings (“Security upgrade
available”, “Suhosin flags are wrong”, etc.

See bug #28760 for the new bug.

(In reply to comment #1)

Another solution would be to automatically split up requests on the client if
the get query is going to be too long. I prefer however the server config
change option.

This is by far the most robust solution, in my opinion.

I'll work on this today and implement both Trevor/Andrew's suggestion (split up requests if too long) and Max's suggestion (shorten URLs drastically so this hopefully doesn't ever happen in practice). I would like requests to be broken up as infrequently as possible, because every time that happens we take a performance hit.

(In reply to comment #11)

I'll work on this today and implement both Trevor/Andrew's suggestion (split up
requests if too long) and Max's suggestion (shorten URLs drastically so this
hopefully doesn't ever happen in practice). I would like requests to be broken
up as infrequently as possible, because every time that happens we take a
performance hit.

Try doing it with a config option, that way those who can optimize their setup to avoid splitting up requests where they would be by default.

Configurable requests splitting implemented in r87203. I'll refine this later by checking for suhosin.get.max_value_length in the installer and setting $wgResourceLoaderMaxQueryLength appropriately in the generated LocalSettings.php file, and by implementing the parameter shortening scheme MaxSem suggested.

Installer check added in r87494. This makes sure fresh installs with suhosin.get.max_value_length set will have the appropriate value for $wgResourceLoaderMaxQueryLength in their LocalSettings.php ; not sure how to do this cleanly for upgrades, will ask Chad.

(In reply to comment #4)

In addition to saving on module names, it also sends 1 byte for comma instead
of 3 bytes for pipe which you have to percent-encode.

Turns out that's not true: jQuery is encoding my commas and colons as well.

(In reply to comment #4)

Possible URL reduction method:

&modules=jquery:autoEllipsis,checkboxShiftClick,client,collapsibleTabs|jquery.ui:button,core,dialog

Implemented this in r87497, except that I'm using dots instead of colons because 1) that's one fewer character with a special meaning and 2) the fact that a dot is one character after urlencoding but a colon is three is inconvenient when doing the query string length bookkeeping required to avoid hitting the limit.

So the URL from your example now looks like this:

&modules=jquery.autoEllipsis,checkboxShiftClick,client,collapsibleTabs|jquery.ui.button,core,dialog

Closing this bug as FIXED because I believe I've done every reasonable thing that can be done to address this issue. Maybe we can do something in the upgrader too, but I'll have to ask Chad about that.

• Bug 29056 has been marked as a duplicate of this bug. ***