7 votes

Contrôle d'accès Autoriser l'origine dans une servlet

Je reçois une requête d'un JSP (de l'iPad) vers une Servlet (de mon système). Lorsque j'envoie la réponse à la JSP, le navigateur et l'application iPad semblent rejeter les données provenant du proxy en raison de l'absence d'en-tête.
J'ai défini l'en-tête comme

           response.setHeader("Access-Control-Allow-Origin","*");

Access-Control-Allow-Origin est le nom de l'en-tête provenant de l'iPad.
J'ai vu dans le lien suivant http://en.wikipedia.org/wiki/List_of_HTTP_header_fields qu'il n'y a pas de type d'en-tête Access-Control-Allow-Origin dans la Servlet.
Puisque les tests se déroulent à différents endroits, pouvez-vous me dire que le setheader que j'ajoute est write one.

6voto

home Points 8667

Vous interprétez mal l'entrée de WikiPedia. Dans une servlet, vous êtes autorisé à définir n'importe quel en-tête de réponse que vous voulez. La seule contrainte est que les clients doivent être capables de comprendre l'en-tête. Wikipedia liste les officiel Les en-têtes HTTP sont disponibles conformément aux RFC 2616 et 4229 (voir le lien que vous avez fourni). Les en-têtes propriétaires et personnalisés sont légaux et souvent utilisés.

En général, il suffit de définir le paramètre Access-Control-Allow-Origin lorsqu'il s'agit de requêtes script inter-domaines, par exemple la JSP récupérée à partir de domain1.com effectue une requête côté client (JavaScript, AJAX) vers une servlet hébergée sur domaine2.com . En fonction de votre cas d'utilisation, vous devez décider si vous avez besoin de l'en-tête ou non. La spécification officielle est disponible aquí . Vous devriez le lire attentivement... croyez-moi !

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X