Autocomplete broken for servers enforcing clean URLs

Thank you for opening the issue, as I stated in the original issue, this security fix actually breaks lots of sites, where we don't want to expose index.php and fully disable and disallow clean URL.

Re-rolling the patch with minor fixes: variable name + else identation.

Patch recreated by strictly following https://www.drupal.org/node/3060/git-instructions/7.x/nonmaintainer

thank you for this.
I am using Varnish.
none of the autocomplete functionality would work.
this patch and the accompanying addition to settings.php has solved the problem

If we're really going to allow people to undo a security feature by setting a variable, this needs some clear documentation of the specific security risks involved.

And we also need to be clear about why we're providing that option. I'm still not 100% clear on it myself, and the issue summary here seems to be intertwining a couple unrelated things. To summarize how I see it:

1. If the problem is because your server blocks index.php, then you don't need the patch in this issue:
   • You can use https://www.drupal.org/node/2599326#comment-10876408 instead (and someone could easily move that to a contrib module if they wanted) which is a way better solution because it preserves the security fix.
   • Or, you could just stop blocking index.php!... I still haven't seen anyone give a good reason why a server that expects to have PHP web applications running on it should want to block index.php from being accessed. Some of the reasons mentioned in the issue summary here (e.g. "unclean log files/Google Analytics data") should be solved by redirecting index.php requests to strip the "index.php" part out, not blocking them. That's a totally different thing altogether and completely reasonable, and Drupal should already work fine with that.
2. If the problem is because your server blocks unclean URLs (i.e. prevents requests that look like example.com/?q=some/path from coming to Drupal) then that's a bit of a different story and your problem dates back to the original security release itself. My question would still be similar as above: why not redirect rather than block? (see also #2554203: Security fix in Drupal 7.39 may cause inefficient autocomplete when used with Global Redirect) You probably lose part of the security protection if you redirect (just like if you block), but it's more of a secondary security protection anyway, and then you don't have the problem with autocomplete plus will avoid other potential problems as well.

   I can see more of an argument for the patch in this issue based on people in this situation, but it still sounds like a highly unusual configuration and it would be preferable not to complicate the core code for that. If you really need to block those ?q= requests entirely, any reason not to deal with the autocomplete problem via custom/contrib code too (it should be possible to use hook_element_info_alter() to add another process function that runs after form_process_autocomplete() and switches the URL then)?

Bumping to 7.70. This didn't make it into 7.60.