Bonjour,
Depuis hier, impossible de faire appel à l’api adresse en « Request Method : OPTIONS ». Erreur : 405 Not Allowed. Est-ce dû à un changement de votre coté ?
Request URL: https://api-adresse.data.gouv.fr/search/?q=45140&postcode=45140&type=municipality&limit=30&_dc=1534840945294
Request Method: OPTIONS
Status Code: 405 Not Allowed
Il y a en effet eu un changement de notre côté, pour vérifier que les bonnes méthodes HTTP étaient utilisées sur les 4 types de requêtes: GET pour les requêtes unitaires, POST pour les requêtes par lot.
Pouvez-vous indiquer l’utilité de ce type de requête OPTIONS ? Elles ne retournent pas de résultat… d’où ma question.
OPTIONS est de plus une méthode optionnelle d’après les dernières RFC sur HTTP/1.1, un serveur HTTP n’a pas obligation de les accepter.
Les requêtes OPTIONS (dans mon cas) sont des requêtes de contrôle préliminaires (Preflighted requests) qui apparaissent lorsqu’un navigateur tente d’accéder à l’API via mon site.
Les navigateurs et les serveurs HTTP récents suivent le standard promulgué par le W3C sous le nom de CORS pour atteindre et partager des ressources.
Ce standard impose une « pré-requête » via OPTIONS dans de très nombreux cas. Ici c’est l’utilisation d’un Content-type « application/json » conformément aux spécifications HTTP/1.1 qui entraîne ce contrôle.
Bref en indiquant au navigateur qu’il doit obtenir du json (utf8), ce dernier vérifie au préalable que votre serveur en est capable et nous y autorise avant d’envoyer la moindre donnée.
Ce mécanisme a été implémenté pour éviter des attaques de type CSRF. Le serveur peut ainsi répondre aux requêtes légitimes (GET/POST, uniquement sur des chemins donnés par exemple) tout en refusant les autres.
Liens utiles :
https://www.w3.org/TR/cors/
Plus d’infos sur le paramétrage côté serveur :
La très grande majorité des utilisateurs de notre API n’ont pas eu besoin de ces OPTIONS avant un requête GET (ou POST) jusqu’à ce jour (et ce depuis 2015).
Après renseignement pris auprès de mes collègues (CORS n’est pas ma spécialité), les requêtes de « pre-flight » utilisant OPTIONS n’ont pas de raison d’être sur des GET et POST n’utilisant pas d’entête particuliers.
Ceci figure d’ailleurs dans le second lien de votre réponse : https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests
Vu que vous faites référence à l’entête « Content-Type », celui-ci n’a pas de raison d’être sur une requête GET qui ne contient (en principe) pas de contenu, et le content-type de réponse ne peut pas déclencher de pre-flight, le navigateur ne connaissant pas ce dernier.
Si vous voulez indiquer que vous souhaitez une réponse en json, c’est un « Accept: application/json » qu’il faut envoyer et Accept fait partie des entêtes de requêtes simples, et ne nécessitera donc pas de pre-flight.
Cet « Accept » est toutefois superflu vu que notre API ne fournit que des réponses en json sur les GET.
Vérifiez donc que c’est bien un Accept et non un Content-Type que vous envoyez dans vos requêtes.
Pourquoi souhaitons-nous limiter ces requêtes OPTIONS ?
Si ceci est indispensable pour vous, nous vous rappelons que vous pouvez déployer votre propre instance de notre géocodeur addok et que nous avons pour cela préparé un docker prêt à déployer pour plus de facilité: https://github.com/etalab/addok-docker