L’histoire est quelque peu ubuesque, et remonte à il y a 16 ans via 26a1f490
qui a déplacé des règles trop bas. Ça ne bloquait plus les .svn depuis,
à cause du fait que plus haut, si c’est un fichier, on exécute la règle
`[S=100]` qui saute les prochaines `RewriteRule`.

- #5109 a semblé corriger en utilisant `RedirectMatch`, qui n’est pas affecté
  par le Skip (sans se rendre compte du problème initial)
- #5432 a remis une `RewriteRule`, et du coup, de nouveau paf.

Ce n’est pas toujours très visible car les serveurs eux-mêmes bloquent
déjà souvent ces répertoires cachés.

Donc, on remonte bien plus haut les règles de blocage des fichiers cachés
et on leur fait un titre dédié.

Refs: #5109 #5432 spip-team/securite#4844

Fix: #5432

fix: les PDF envoyés avec un CSP Sandbox ne sont pas visibles dans Safari ou Chrome, on fait donc une exception pour ces fichiers

Refs: #5316

Refs: https://git.spip.net/spip-team/securite/issues/4832

On résout aussi doublement l'un des cas d'utilisation de #4445 en permettant aux API de se lancer aussi depuis ecrire/

Il restait des liens en http alors que nous sommes en https, cela fonctionnait, mais c’est toujours mieux :)
Il manquait surtout là: https://git.spip.net/spip/spip/src/branch/master/prive/login.html#L44

Il y a deux endroits, je ne pense pas que mettre https posera de problème, mais je préfère le dire des fois que :)
https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/configurer_relayeur.php#L23
et
https://git.spip.net/spip/spip/src/branch/master/prive/ical_prive.html#L9

#4557

pour certaines API il est vital d'etre a la racine du site, et pas dans un sous repertoire. On permet donc d'utiliser indifferement un . ou un / dans les URLs d'appel aux API
ex : https://site/offline.api.sw.js

Nettoyage de code : disons que ce n’est plus la peine de conserver une compatibilité avec des urls issues de SPIP 1.8 (et 1.9 pour les actions rss/ical).

Fix #2745 : ajouter au htaccess la règle qui permet de servir les favicons des itrucs (commentée par défaut)

bloquer l'accès aux fichiers cachés cf http://archives.rezo.net/archives/spip-dev.mbox/OJPZXTWELE7YCVIWLHHNOTDQBFX2PH4I/

Intégrer un morceau du htaccess (à tester donc) de Symfony qui calcule automatiquement le RewriteBase. De la sorte, un même site appellé depuis la racine (par exemple avec un alias apache) ou depuis un sous répertoire peut gérer les urls propres sans modifier le htaccess.

( https://github.com/symfony/symfony-standard/blob/master/web/.htaccess )
Intégré chez symfony par https://github.com/symfony/symfony-standard/commit/3a4f0e70f455855d2e7f2de18676f28bcf5f5d72

Merci à eux.

Dans un cas où le serveur est configuré avec un expire sur text/html, le privé est mis en cache par firefox > à je ne sais combien et pète svp notamment... Il n'y avait pas de problème similaire en 2.1 ou avant les derniers upgrade...

cf le message de marcimat là http://technique.arscenic.org/lamp-linux-apache-mysql-php/apache/optimisations/article/expire-headers#forum168 dont j'ai eu l'expérience aussi

Autant l'éviter si possible ici 

Changement du format des APIs : on utilise un "." dans le déclancheur, ce qui évite un conflit avec les URLs propres (qui normalement n'ont pas de "."). De plus on préfixe l'action appelée par "api" ce qui évite de pouvoir appeler n'importe question action.

Ce qui donne : 
http://site/xmlrpc.api => action=api_xmlrpc
http://site/atom.api/patates/1234 => action=api_atom&arg=patates/1234

Allez on teste une petite nouveauté. En attendant un jour une vraie gestion du routage des URLs, on va prendre rapidement en compte des URLs propres pour les APIs.

Le htaccess sait donc gérer :
http://site/api/truc => action=truc
http://site/api/truc/bidule/32 => action=truc&arg=bidule/32

Le premier bloc après le slash correspond au nom d'une action, et tout ce qui suit sera "arg". Évidemment ça garde la query string qu'il y aurait en plus.

On peut donc écrire :
http://site/api/xmlrpc
http://site/api/atom/patates/1234

gestion native de sitemap, via htaccess ; pour des sitemaps plus complexes, configurables etc, cf. le plugin sitemap

debug et complement pour l'API d'urls : separer la detection du type et la modification du fond ; permet de respecter un ?page=xxx indique dans le .htaccess ; au passage on se debarrasse enfin de l'affreux ?page=type_urls (mais compat ascendante assuree)

Nouvel htaccess pour evacuer complètement les pseudo-actions rss et ical maintenant que [12430] assure que les clés de hachage sont les mêmes. Si qq sait comment MODIFIER la query-string, pas seulement la compléter ou la remplacer, je suis preneur.

revision de la possibilite de faire une transition entre une mode d'url et un autre ; a noter les rubriques en arbo ne transitionnent pas vers les autres modes (juste pour ca, il faudrait tout revoir : on surseoit)

 * Variantes :
 * pour avoir des url terminant par html
 * define ('_terminaison_urls_arbo', '.html');
 * 
 * pour avoir des url numeriques (id) du type 12/5/4/article/23
 * define ('_URLS_ARBO_MIN',255);
 * 
 * pour avoir des url sans les types 
 * define ('_urls_arbo_sans_type',1);
 * 
 * pour conserver la casse des titres dans les url
 * define ('_url_arbo_minuscules',0);
 * 
 * pour choisir le caractere de separation titre-id en cas de doublon 
 * (ne pas utiliser '/')
 * define ('_url_arbo_sep_id','-');
 * 
 * pour modifier la hierarchie apparente dans la constitution des urls
 * ex pour que les mots soient classes par groupes
 * $GLOBALS['url_arbo_parents']=array(
 *			  'article'=>array('id_rubrique','rubrique'),
 *			  'rubrique'=>array('id_parent','rubrique'),
 *			  'breve'=>array('id_rubrique','rubrique'),
 *			  'site'=>array('id_rubrique','rubrique'),
 * 				'mot'=>array('id_groupe','groupes_mot'));

/titrerub1/titrerub2/titrerub3/article/titrearticle
il peut rester des bugs

#1071 un htaccess plus a jour, et remise a niveau d'un vieux code pour le traitement des urls propres dont on se demande comment il marchait
(peut etre cela a-t-il un rapport avec #1171 ?)

Simplication des URLs propres (suite de [10203] et [10209]). Les marqueurs de types d'URL sont totalement évacués, car en fait ils n'étaient pas inclus dans la chaîne stockée dans la table SQL, on ne gaspille pas de place dans cette table en les évacuant et l'URL est alors plus agréable à lire. On continue en revanche à les retirer dans les URLS demandées au serveur HTTP afin d'assurer le service pour les anciens signets.

Le .htacces est donc simplifié et mérite d'être recopié à partir du htaccess.txt fourni. Le titre général du seul paramètre page qui y figure encore est désormais '''type_urls''' pour avoir un message d'erreur plus clair lorsque la variable homonyme n'a pas été affectée dans mes_options.

Enfin, le couteux '''charger_generer_url''' qui cherche d'abord les anciens fichiers '''.php3''' n'est plus appelé dans ce cadre qu'en dernier recours, les différentes définitions de '''recuperer_parametre_url''' étant remplacées par la famille '''urls_propres_dist urls_html_dist urls_page_dist''' etc, avec le '''charger_fonction''' usuel. Pour ceux qui ont leur '''type_urls''' personnels, la compatibilité est normalement assurée, mais renommer leur  '''recuperer_parametre_url''' leur fera bénéficier de cette amélioration.