en-tête de réponse jQuery et AJAX

la solution de cballou fonctionnera si vous utilisez une ancienne version de jquery. Dans les versions plus récentes, vous pouvez également essayer:

  $.ajax({
   type: 'POST',
   url:'url.do',
   data: formData,
   success: function(data, textStatus, request){
        alert(request.getResponseHeader('some_header'));
   },
   error: function (request, textStatus, errorThrown) {
        alert(request.getResponseHeader('some_header'));
   }
  });

Selon les docs l'objet XMLHttpRequest est disponible à partir de jQuery 1.4.

S'il s'agit d'une requête CORS , vous pouvez voir tous les en-têtes dans les outils de débogage (tels que Chrome->Inspect Element - >Network), mais l'objet xHR ne récupérera l'en-tête (via xhr.getResponseHeader('Header') ) si un tel en-tête est un simple response header :

• Content-Type
• Last-modified
• Content-Language
• Cache-Control
• Expires
• Pragma

si elle n'est pas dans cet ensemble, elle doit être présente dans l'en-tête Access-Control-Expose-Headers retourné par le serveur.

dans le cas en question, s'il s'agit d'une requête CORS, on ne pourra récupérer l'en-tête Location que par l'objet XMLHttpRequest si, et seulement si, l'en-tête ci-dessous est aussi présente:

Access-Control-Expose-Headers: Location

si ce n'est pas une demande de CORS, XMLHttpRequest n'aura aucun problème pour la récupérer.

 var geturl;
  geturl = $.ajax({
    type: "GET",
    url: 'http://....',
    success: function () {
      alert("done!"+ geturl.getAllResponseHeaders());
    }
  });

la triste vérité sur AJAX et la redirection 302 est que vous ne pouvez pas obtenir les en-têtes à partir du retour parce que le navigateur ne les donne jamais à la XHR. Lorsqu'un navigateur voit un 302 il s'applique automatiquement la redirection. Dans ce cas, vous verriez la tête dans firebug, car le navigateur a obtenu, mais vous ne serait pas la voir en ajax, parce que le navigateur n'a pas le passer. C'est pourquoi la réussite et les gestionnaires d'erreur jamais appelée. Seul le gestionnaire complet est appelé.

http://www.checkupdown.com/status/E302.html

The 302 response from the Web server should always include an alternative URL to which redirection should occur. If it does, a Web browser will immediately retry the alternative URL. So you never actually see a 302 error in a Web browser

voici quelques posts stackoverflow sur le sujet. Certains articles décrivent des piratages pour contourner ce problème.

Comment gérer une demande de redirection après un appel Ajax jQuery

Rattrapage 302 TROUVÉ en JavaScript

HTTP redirection: 301 (permanente) vs 302 (temporaire)

l'objet XMLHttpRequest sous-jacent utilisé par jQuery suivra toujours silencieusement les redirections plutôt que de retourner un code de statut 302. Par conséquent, vous ne pouvez pas utiliser la fonctionnalité de requête AJAX de jQuery pour obtenir l'URL retournée. Au lieu de cela, vous devez mettre toutes les données dans un formulaire et soumettre le formulaire avec le target attribut mis à la valeur de l'attribut name de l'iframe:

$('#myIframe').attr('name', 'myIframe');

var form = $('<form method="POST" action="url.do"></form>').attr('target', 'myIframe');
$('<input type="hidden" />').attr({name: 'search', value: 'test'}).appendTo(form);

form.appendTo(document.body);
form.submit();

le la page url.do du serveur sera chargée dans l'iframe, mais lorsque son statut 302 arrivera, l'iframe sera redirigée vers la destination finale.

essayez ceci:

type: "GET",
async: false,
complete: function (XMLHttpRequest, textStatus) {
    var headers = XMLHttpRequest.getAllResponseHeaders();
}

+1 à PleaseStand et voici mon autre hack:

après avoir cherché et trouvé que la" demande ajax croisée " ne pouvait pas obtenir des en-têtes de réponse de l'objet XHR, j'ai abandonné. et utilisez iframe à la place.

1. <iframe style="display:none"></iframe>
2. $("iframe").attr("src", "http://the_url_you_want_to_access")
//this is my aim!!!
3. $("iframe").contents().find('#someID').html()