Issue #2116395 by realityloop - Nginx: Extend protection for config files and use 404 instead of 403.

Nginx: Replace inappropriate, legacy keyword gulag with neutral and technically correct limreq everywhere.

The cache_form bin is excluded in drupal_flush_all_caches() but if not purged, it may break tasks with mysterious errors thanks to garbage collected.

Nginx: Separate support for static and dynamic .json requests/URIs to avoid breaking Services for GET requests.

This assumes that static .json files with fast 404 are expected only in the sites/foo.com/files tree. Everything else is expected to be dynamic and sent to Drupal via Speed Booster caching layer only.

See http://trac.nginx.org/nginx/ticket/306 for context and more details.

Nginx: Add support for domain specific /robots.txt mapped to static files/$host.robots.txt to make it possible to manage it per domain also when Domain Access module is used.

Nginx: Move AJAX and webform requests location after civicrm location to avoid breaking URIs like civicrm/packages/kcfinder/js/browser/joiner.php

Nginx: Deny spiders on glossary/* URI, as they are never allowed to crawl more than one page with args anyway.

Christopher Gervais authored Jun 19, 2013 and Grazyna Jaworska committed Jun 20, 2013

we used to take only the first IP that was set in the server context.

instead we just don't set those IPs in the server context, as they date back
from when we had IP-based virtual hosting even on port 80, and set it properly
in the site context

Christopher Gervais authored Jun 19, 2013 and Grazyna Jaworska committed Jun 20, 2013

this would have destroyed the whole ssl.d directory, wheepee.

anarcat authored Jun 14, 2013 and Grazyna Jaworska committed Jun 20, 2013

this code is not present in core's settings.php since at least Drupal 5.23

anarcat authored May 31, 2013 and Grazyna Jaworska committed Jun 20, 2013

we are not getting all possible contexts because there's no easy way
to enumerate them, so instead we just don't check

Otherwise web server can't write there, so even if we use Drush for cron, and it will run as an Aegir backend user, which has the write access there (and also limited shell user can write there) the module itself will refuse to work on scheduled cron run, because the backup directories are expected to be writable by the web server. This is required also when standard wget method for cron is used.