Safari 10.1: XMLHttpRequest avec les paramètres de la requête ne peut pas charger en raison de l'accès de contrôle vérifie

Si vous essayez une de la SCRO demande sur Safari 10.1, sur une URL qui comprend des paramètres de requête (par exemple,https://example.com/api?v=1), Safari dit

XMLHttpRequest ne peut pas charger en raison de l'accès de contrôle vérifie

Chrome/Firefox, beau travail.

Sur demande à partir de la page sans le "?v=1", Safari fonctionne très bien aussi.

J'ai essayé de changer de serveur en-tête de réponse de

Access-Control-Allow-Origin: https://example.com

à

Access-Control-Allow-Origin: https://example.com/api?v=1

mais que les sauts de Chrome.

Des suggestions?

  • essayez avec encodeURI('https://example.com/api?v=1')
  • essayé, pas de changement: Réponse à la demande de contrôle en amont ne passent pas de contrôle d'accès: Le "Access-Control-Allow-Origin' en-tête a une valeur 'test.com/page?v=1 " qui n'est pas égal à celui fourni d'origine. Origine 'test.com' est donc pas autorisé à accéder.
  • J'ai le même problème avec Safari lors de l'exécution d'un site localement.
  • Avez-vous tout de trouver une solution @Gaz ou Marius?
  • Apparemment avoir le même problème ici. - Nous tout simplement désactiver l'utilisation de paramètres de requête pour garder Safari heureux?
  • Avez-vous lu ce post?: discussions.apple.com/message/31846683#31846683 la réponse est curieux, en raison de malware? je n'ai pas de MAC mais des bruits étranges
  • access-control-allow-origin est un peu le vertige... pourriez-vous spécifier correctement l'url de votre page html, l'url où les demandes XHR contenu et le serveur où vous avez ajouté access-control-allow-origin pour?
  • Je sais que c'est 8 mois de retard, mais avez-vous comparé les en-têtes dans les différents scénarios? Je demande parce que de cette solution, même si ce n'est pas de chaîne de requête relative: stackoverflow.com/a/22924272/2133723 Safari a été la définition de certains en-têtes n'étaient pas autorisés.
  • Ou essayez avec encodeURIComponent(https://example.com/api?v=1)

InformationsquelleAutor Marius Andreiana | 2017-04-20
  1. 3

    Essayer suivantes pourraient travailler - 

    Access-Control-Allow-Origin: <origin> | *
    • où voulez-vous ajouter/modifier des que
    InformationsquelleAutor mdeora
  2. 2

    Vous êtes en cours d'exécution dans la SCRO questions.

    Quelques causes possibles:

    • L'en-tête Access-Control-Allow-Origin ne peut être réglé que sur le côté serveur, pas dans vos clients de script. (Vous n'avez pas clair, vous avez fait correctement).
    • Êtes-vous sûr que le protocole (http vs https vs peut-être même file) est exactement la même chose?
    • Si vous pouvez avoir plusieurs sous-domaines que vous devez configurer votre fichier de configuration (par exemple Apache) avec quelque chose comme "^http(s)?://(.+\.)?test\.com$
      .

      Le ^ marque le début de la ligne pour éviter le précédant cette url. Vous avez besoin d'un protocole et permettant à la fois ici. Un sous-domaine est en option. Et le $ marque la fin de la ligne (vous n'avez pas besoin de définir le sous-pages, parce que l'origine est uniquement basé sur l'hôte).
    • Comme indiqué ici ajoutant Access-Control-Allow-Headers: Origin à la configuration de serveur en tant que bien peut être une solution. Essayez de comparer le réel demandes mon Safari au succès de la demande faite par Firefox ou Chrome pour repérer d'éventuels disparus en-Têtes (et peut-être de les comparer à votre configuration de serveur en tant que bien).
    InformationsquelleAutor Seika85
  3. 1

    Si quelqu'un vient sur cette erreur, il vient de se produire dans l'application, j'ai été la construction. Dans mon cas, il s'est avéré être une fin /dans l'uri, qui a provoqué un 301 de la réponse, qui a été pour quelque raison interprété par Safari comme une réponse 500.

    InformationsquelleAutor Christian Kaal