[Apprendre Ajax en quatre jours] Le troisième jour d'apprentissage du tutoriel Ajax, requêtes et réponses avancées en Ajax

Auteur：Eve Cole Date de mise à jour：2009-07-06 16:36:51

Pour de nombreux développeurs Web, générer des requêtes simples et recevoir des réponses simples est suffisant ; mais pour les développeurs qui souhaitent maîtriser Ajax, une compréhension complète des codes d'état HTTP, des états prêts et de l'objet XMLHttpRequest est nécessaire. Dans cet article, Brett McLaughlin vous présente les différents codes d'état et vous montre comment les navigateurs les gèrent. Il examine également certaines des requêtes HTTP les moins courantes utilisées dans Ajax.

Dans l'article précédent de cette série, nous avons examiné de plus près l'objet XMLHttpRequest, qui est la pièce maîtresse d'une application Ajax et est responsable du traitement des requêtes des applications et des scripts côté serveur et du traitement des données renvoyées par les composants côté serveur. Étant donné que toutes les applications Ajax utilisent l'objet XMLHttpRequest, vous souhaiterez peut-être vous familiariser avec cet objet afin qu'Ajax puisse mieux fonctionner.

Dans cet article, je me concentrerai sur les trois parties clés de cet objet de requête sur la base de l'article précédent :

· Statut prêt pour HTTP · Code d'état HTTP · Les types de requête qui peuvent être générés.

Ces trois parties participent toutes à la construction d'un facteur à prendre en compte. cependant, lors de la demande, trop peu d'écrits ont été écrits sur ces sujets. Cependant, si vous souhaitez en savoir plus que les bases de la programmation Ajax, vous devrez vous familiariser avec le contenu des états prêts, les codes d'état et les requêtes elles-mêmes. Lorsque quelque chose ne va pas avec votre application - et c'est toujours le cas - si vous comprenez correctement l'état de préparation, comment générer une requête HEAD ou ce que signifie exactement un code d'état 400, vous pouvez déboguer le problème en 5 minutes au lieu de 5 heures passées. dans diverses frustrations et confusions.

Examinons d'abord l'état HTTP prêt.

Examen plus approfondi de l'état HTTP prêt

Vous vous souviendrez de l'article précédent que l'objet XMLHttpRequest possède une propriété appelée readyState. Cet attribut garantit que le serveur a terminé une demande, en utilisant généralement une fonction de rappel pour lire les données du serveur afin de mettre à jour le contenu du formulaire ou de la page Web. Le listing 1 montre un exemple simple (c'est aussi un exemple de l'article précédent de cette série - voir Ressources).

XMLHttpRequest ou XMLHttp : un changement de nom

Microsoft™ et Internet Explorer utilisent un objet appelé XMLHttp au lieu de l'objet XMLHttpRequest, qui est utilisé par Mozilla, Opera, Safari et la plupart des navigateurs non Microsoft. Par souci de simplicité, j'appellerai simplement les deux objets XMLHttpRequest. Cela est cohérent à la fois avec ce que nous voyons sur le Web et avec l'intention de Microsoft d'utiliser XMLHttpRequest comme objet de requête dans Internet Explorer 7.0. (Voir la partie 2 pour en savoir plus sur ce problème.)

Listing 1. Gestion de la réponse du serveur dans une

fonction de rappel updatePage() {
si (request.readyState == 4) {
si (request.status == 200) {
var réponse = request.responseText.split("|");
document.getElementById("order").value = réponse[0];
document.getElementById("adresse").innerHTML =
réponse[1].replace(/n/g, "<br />");
} autre
alert("le statut est " + request.status);
}
}

C'est évidemment l'utilisation la plus courante (et la plus simple) de l'état prêt. Comme vous pouvez le constater d'après le chiffre "4", il existe plusieurs autres états prêts (vous avez également vu cette liste dans l'article précédent - voir Ressources) :

· 0 : La requête n'est pas initialisée (open() n'a pas encore été appelé) .
·1 : La requête a été établie, mais n'a pas été envoyée (send() n'a pas encore été appelée).
·2 : La demande a été envoyée et est en cours de traitement (généralement, les en-têtes de contenu peuvent maintenant être obtenus à partir de la réponse).
·3 : La demande est en cours de traitement ; généralement certaines données sont disponibles dans la réponse, mais le serveur n'a pas encore fini de générer la réponse.
·4 : La réponse est complète ; vous pouvez obtenir et utiliser la réponse du serveur.

Si vous souhaitez comprendre plus que les bases de la programmation Ajax, vous devez connaître non seulement ces états, mais aussi quand ils se produisent et comment les utiliser. Tout d’abord, vous devez connaître les états de requête que vous pourriez rencontrer dans chaque état de préparation. Malheureusement, cela n’est pas intuitif et implique plusieurs cas particuliers.

État prêt caché

Le premier état prêt est caractérisé par l'attribut readyState étant 0 (readyState == 0), indiquant un état non initialisé. Cette propriété est définie sur 1 une fois que open() est appelé sur l'objet requête. Puisque vous appelez habituellement open() immédiatement après avoir initialisé une paire de requêtes, vous verrez rarement un état readyState == 0. De plus, l’état prêt non initialisé n’a aucune réelle utilité dans les applications réelles.

Mais pour notre intérêt, voir le listing 2, qui montre comment obtenir cet état prêt lorsque readyState est défini sur 0.

Listing 2. Obtenir le statut 0 prêt

fonction getSalesData() {
//Créer un objet requête
createRequest();
alert("L'état prêt est : " + request.readyState);

// Configure (initialise) la requête
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Dans cet exemple simple, getSalesData() est la fonction que la page Web appelle pour lancer une requête (par exemple lorsqu'un clic sur un bouton est effectué). Notez que vous devez vérifier l'état prêt avant d'appeler open(). La figure 1 montre les résultats de l'exécution de cette application.

Figure 1. État prêt 0

Évidemment, cela ne vous rapporte pas grand chose ; il existe très peu de situations dans lesquelles vous devez vous assurer que la fonction open() n'a pas encore été appelée. Dans le monde réel de la plupart des programmations Ajax, la seule utilisation de cet état prêt est d'utiliser le même objet XMLHttpRequest pour générer plusieurs requêtes sur plusieurs fonctions. Dans ce cas (rare), vous souhaiterez peut-être vous assurer que l'objet de requête est dans un état non initialisé (readyState == 0) avant de générer une nouvelle requête. Cela garantit essentiellement qu'une autre fonction n'utilise pas l'objet en même temps.

Afficher l'état de préparation de la demande en cours de traitement

. En plus de l'état prêt 0, l'objet de la demande doit également passer par plusieurs autres états prêts de demandes et de réponses typiques, et se termine finalement sous la forme d'un état prêt 4. C'est pourquoi vous voyez la ligne if (request.readyState == 4) dans la plupart des fonctions de rappel ; elle garantit que le serveur a fini de traiter la requête et qu'il est désormais possible de mettre à jour la page Web en toute sécurité en fonction de la requête renvoyée. à partir des données du serveur pour effectuer des opérations.

Il est très simple de voir comment cet état se produit. Si l'état prêt est 4, non seulement nous devons exécuter le code dans la fonction de rappel, mais nous imprimons également l'état prêt à chaque fois que la fonction de rappel est appelée. Le listing 3 donne un exemple d'implémentation de cette fonctionnalité.

Lorsque 0 est égal à 4

, vous devez vérifier l'état prêt 0 pour vous assurer que l'objet de requête n'est pas utilisé lorsque plusieurs fonctions JavaScript utilisent le même objet de requête. Ce mécanisme peut provoquer des problèmes. Puisque readyState == 4 représente une requête terminée, vous constaterez souvent que les objets de requête à l'état prêt qui ne sont pas actuellement utilisés sont toujours définis sur 4 - c'est parce que les données renvoyées par le serveur ont déjà été utilisées, mais non. des modifications ont été apportées depuis qu'ils ont été mis à l'état prêt. Il existe une fonction abort() qui réinitialise l'objet requête, mais cette fonction n'est pas vraiment utilisée à cet effet. Si vous devez utiliser plusieurs fonctions, il est préférable de créer et d'utiliser une fonction pour chaque fonction plutôt que de partager le même objet entre plusieurs fonctions.

Listing 3. Afficher

la fonction de préparation updatePage() {
// Affiche l'état prêt actuel
alert("updatePage() appelé avec l'état prêt de " + request.readyState);
}

Si vous ne savez pas comment exécuter cette fonction, vous devez créer une fonction, puis appeler cette fonction dans la page Web et lui demander d'envoyer une requête au composant côté serveur (comme la fonction présentée dans le listing 2, ou la fonction dans cette série d'articles) Exemples donnés dans la partie 1 et la partie 2). Assurez-vous de définir la fonction de rappel sur updatePage() lors de la requête ; pour ce faire, définissez la propriété onreadystatechange de l'objet de requête sur updatePage().

Ce code est une démonstration exacte de la signification de onreadystatechange - chaque fois que l'état prêt de la requête change, updatePage() est appelé, et nous pouvons alors voir un avertissement. La figure 2 montre un exemple d'appel de cette fonction, où l'état prêt est 1.

Figure 2. État prêt 1

Vous pouvez essayer d'exécuter ce code vous-même. Placez-le dans une page Web et activez le gestionnaire d'événements (cliquez sur un bouton, tabulez entre les champs ou utilisez la méthode que vous avez définie pour déclencher la demande). Cette fonction de rappel s'exécutera plusieurs fois - à chaque fois que l'état prêt change - et vous pourrez voir l'avertissement pour chaque état prêt. C’est le meilleur moyen de suivre les différentes étapes par lesquelles passe une demande.

Incohérences du navigateur

Une fois que vous avez une compréhension de base du processus, essayez d'accéder à votre page à partir de plusieurs navigateurs différents. Vous devriez remarquer que les navigateurs sont incohérents dans la façon dont ils gèrent ces états prêts. Par exemple, dans Firefox 1.5, vous verriez les états prêts suivants :

·1
·2
·3
·4

Cela n'est pas surprenant puisque chaque statut de demande est représenté ici. Cependant, si vous utilisez Safari pour accéder à la même application, vous devriez voir – ou non – quelque chose d'intéressant. Voici à quoi cela ressemble dans Safari 2.0.1 :

·2
·3
·4

Safari supprime en fait le premier état prêt, et il n'y a aucune raison évidente à cela, mais c'est ainsi que Safari fonctionne. Cela illustre également un point important : même si c'est une bonne idée de s'assurer que le statut de la requête est 4 avant d'utiliser les données sur le serveur, le code écrit pour s'appuyer sur chaque état de transition prêt aura en effet un aspect différent selon les navigateurs.

Par exemple, lors de l'utilisation d'Opera 8.5, l'état de préparation affiché est encore pire :

·3
·

4Enfin, Internet Explorer affichera l'état suivant :

·1
·2
·3
·4Si

vous rencontrez des problèmes avec vos demandes, c'est le premier endroit où vous adresser pour identifier le problème. La meilleure façon est de tester cela dans Internet Explorer et Firefox - vous verrez les 4 états et pourrez vérifier dans quel état se trouve chaque état de la requête.

Examinons ensuite la situation du côté de la réponse.

Les données de réponse au microscope

Une fois que nous avons compris les différents états de préparation qui se produisent au cours du processus de requête, il est temps d'examiner un autre aspect de l'objet XMLHttpRequest : l'attribut ResponseText. Rappelons ce que nous avons introduit dans l'article précédent, vous pouvez savoir que cet attribut est utilisé pour récupérer les données du serveur. Une fois que le serveur a fini de traiter la demande, il peut placer toutes les données nécessaires pour répondre aux données de la demande dans le texte de réponse de la demande. La fonction de rappel peut ensuite utiliser ces données, comme indiqué dans le listing 1 et le listing 4.

Listing 4. Utilisation de la réponse renvoyée sur le serveur

fonction updatePage() {
si (request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("total-vendu");
var netProfitEl = document.getElementById("bénéfice net");
replaceText(totalSoldEl, newTotal);

/* Imaginez le nouveau bénéfice net */
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
var profitPerBoard = boardCost - manCost ;
var netProfit = profitPerBoard * newTotal;

/* Mettre à jour le bénéfice net sur le formulaire de vente */
netProfit = Math.round(netProfit * 100) / 100 ;
replaceText(netProfitEl, netProfit);
Le listing

1 est assez simple ; le listing 4 est un peu plus compliqué, mais ils vérifient tous deux l'état prêt au début et obtiennent la valeur de la propriété ResponseText.

Affichage du texte de réponse d'une requête

Semblable à l'état prêt, la valeur de la propriété ResponseText change également tout au long de la durée de vie de la requête. Pour voir ce changement, utilisez le code affiché dans le listing 5 pour tester le texte de réponse de la requête, ainsi que leur état de préparation.

Listing 5. Test de la

fonction de propriété ResponseText updatePage() {
// Affiche l'état prêt actuel
alert("updatePage() appelé avec l'état prêt de " + request.readyState +
" et un texte de réponse de '" + request.responseText + "'");
}

Ouvrez maintenant l'application Web dans votre navigateur et activez votre demande. Pour mieux voir l'effet de ce code, utilisez Firefox ou Internet Explorer, car les deux navigateurs peuvent signaler tous les états de préparation possibles lors de la requête. Par exemple, dans l'état prêt 2, ResponseText n'est pas défini (voir Figure 3) ; si la console JavaScript est également ouverte, vous verrez une erreur.

Figure 3. Texte de réponse pour l'état prêt 2

Cependant, dans l'état prêt 3, le serveur a mis une valeur dans la propriété ResponseText, du moins dans cet exemple (voir Figure 4).

Figure 4. Texte de réponse pour l'état prêt 3

Vous verrez que la réponse avec un statut prêt de 3 est différente sur chaque script, chaque serveur et même chaque navigateur. Cependant, cela reste très utile pour le débogage des applications.

Obtention de données sécurisées

Tous les documents et spécifications soulignent que les données ne peuvent être utilisées en toute sécurité que lorsque l'état de préparation est 4. Croyez-moi, lorsque l'état prêt est 3, vous rencontrerez rarement une situation dans laquelle vous ne pourrez pas obtenir de données de la propriété ResponseText. Cependant, ce n'est pas une bonne idée de rendre votre propre logique dans votre application dépendante de l'état prêt 3 - une fois que vous écrivez du code qui repose sur des données complètes dans l'état prêt 3, vous êtes presque responsable des données incomplètes à ce moment-là.

Une meilleure approche consiste à fournir à l'utilisateur un retour d'information lui indiquant qu'une fois dans l'état prêt 3, la réponse sera bientôt disponible. Bien que l'utilisation de fonctions telles que alert() soit évidemment une mauvaise idée - utiliser Ajax puis bloquer l'utilisateur avec une boîte de dialogue d'alerte est évidemment une erreur - vous pouvez mettre à jour les champs d'un formulaire ou d'une page lorsque l'état prêt change. Par exemple, pour l'état prêt 1, définissez la largeur de l'indicateur de progression sur 25 %, pour l'état prêt 2, définissez la largeur de l'indicateur de progression sur 50 % et pour l'état prêt 3, définissez la largeur de l'indicateur de progression sur 25. % La largeur est définie sur 75 %, et lorsque l'état prêt est 4, la largeur de l'indicateur de progression est définie sur 100 % (terminé).

Bien sûr, comme vous l'avez déjà vu, cette méthode est très astucieuse, mais elle dépend du navigateur. Sur Opera, vous ne voyez jamais les deux premiers états prêts, et sur Safari, il n'y en a pas de premier (1). Pour cette raison, j'ai laissé ce code à titre d'exercice et ne l'ai pas inclus dans cet article.

Il est maintenant temps d'examiner les codes de statut.

Un examen plus approfondi des codes d'état HTTP

Avec l'état prêt et la réponse du serveur que vous avez appris dans les techniques de programmation Ajax, vous pouvez ajouter un autre niveau de complexité à vos applications Ajax - en utilisant les codes d'état HTTP. Il n'y a rien de nouveau à propos d'Ajax dans ce code. Ils existent depuis l'aube du Web. Vous avez peut-être vu plusieurs codes d'état dans les navigateurs Web :

· 401 : non autorisé · 403 : interdit · 404 : introuvable

Vous pouvez trouver davantage de codes d'état (voir Ressources pour une liste complète). Pour ajouter une couche supplémentaire de mécanismes de contrôle et de réponse (et une gestion des erreurs plus robuste) à vos applications Ajax, vous devez afficher correctement les codes d'état dans les demandes et les réponses.

200 : Tout va bien

Dans de nombreuses applications Ajax, vous verrez une fonction de rappel chargée de vérifier l'état de préparation, puis de continuer à utiliser les données renvoyées par la réponse du serveur, comme indiqué dans le listing 6.

Listing 6. Fonction de rappel qui ignore

la fonction de code d'état updatePage() {
si (request.readyState == 4) {
var réponse = request.responseText.split("|");
document.getElementById("order").value = réponse[0];
document.getElementById("adresse").innerHTML =
réponse[1].replace(/n/g, "<br />");
}
}

Cela s'avère être une approche à courte vue et erronée de la programmation Ajax. Si le script nécessite une authentification et que la requête ne fournit pas de certificat valide, le serveur renvoie un code d'erreur tel que 403 ou 401. Cependant, comme le serveur a répondu à la demande, l'état prêt est défini sur 4 (même si la réponse n'était pas celle attendue par la demande). En fin de compte, l'utilisateur n'obtient pas de données valides et de graves erreurs peuvent survenir lorsque JavaScript tente d'utiliser des données de serveur qui n'existent pas.

Il faut un minimum d'effort pour garantir que le serveur non seulement complète une demande, mais renvoie également un code d'état « tout va bien ». Ce code est "200", qui est signalé via l'attribut status de l'objet XMLHttpRequest. Pour vous assurer que le serveur a non seulement terminé une requête, mais a également signalé un statut OK, ajoutez une autre vérification à votre fonction de rappel, comme indiqué dans le listing 7.

Listing 7. Vérification des codes d'état valides

En ajoutant ces quelques lignes de code, vous pouvez confirmer s'il y a un problème et l'utilisateur verra un message d'erreur utile au lieu de simplement voir une page composée de données sorties de leur contexte sans explication.

Redirections et réacheminements

Avant d'entrer dans les détails sur les erreurs, il convient de discuter d'un problème dont vous n'avez pas à vous soucier lorsque vous utilisez Ajax : les redirections. Parmi les codes d'état HTTP, il s'agit de la série 300 de codes d'état, dont :

301 : Déplacé de façon permanente 302 : Trouvé (demande redirigée vers une autre URL/URI)
·305 : Utilisation d'un proxy (la requête doit utiliser un proxy pour accéder à la ressource demandée)

Les programmeurs Ajax peuvent ne pas être trop préoccupés par les problèmes de redirection, pour deux raisons :

·Premièrement, les applications Ajax sont généralement conçues pour être écrites pour un côté serveur spécifique. script, servlet ou application. Les programmeurs Ajax sont moins clairs sur les composants qui disparaissent sans que vous les voyiez. Ainsi, parfois, vous savez que la ressource a été déplacée (parce que vous l'avez déplacée ou parce que vous l'avez déplacée d'une manière ou d'une autre), puis vous modifiez l'URL dans la requête et vous ne rencontrez plus jamais ce résultat.
Une raison plus importante est que les applications et requêtes Ajax sont encapsulées dans un bac à sable. Cela signifie que le domaine qui dessert les pages Web générant des requêtes Ajax doit être le domaine qui répond à ces requêtes. Par conséquent, la page Web fournie par ebay.com ne peut pas envoyer de requête de type Ajax à un script exécuté sur amazon.com ; une application Ajax sur ibm.com ne peut pas envoyer de requête aux servlets exécutés sur netbeans.org.
·Le résultat est que votre requête ne peut pas être redirigée vers un autre serveur sans générer une erreur de sécurité. Dans ces cas, vous n’obtiendrez aucun code de statut. Habituellement, une erreur JavaScript est générée dans la console de débogage. Par conséquent, après avoir suffisamment réfléchi aux codes de statut, vous pouvez ignorer complètement le problème des codes de redirection.

Le résultat est que votre requête ne peut pas être redirigée vers un autre serveur sans générer une erreur de sécurité. Dans ces cas, vous n’obtiendrez aucun code de statut. Habituellement, une erreur JavaScript est générée dans la console de débogage. Par conséquent, après avoir suffisamment réfléchi aux codes de statut, vous pouvez ignorer complètement le problème des codes de redirection.

Erreurs

Une fois que vous recevez le code d'état 200 et réalisez que vous pouvez ignorer en grande partie les codes d'état de la série 300, le seul ensemble de codes dont vous devez vous soucier sont les codes de la série 400, qui illustrent les différents types d'erreurs. Revenez au Listing 7 et notez que lors de la gestion des erreurs, seuls quelques messages d'erreur courants sont affichés à l'utilisateur. Bien qu’il s’agisse d’un pas dans la bonne direction, ces messages ne sont toujours pas très utiles pour indiquer aux utilisateurs et aux programmeurs travaillant sur l’application ce qui ne va pas exactement.

Tout d’abord, nous ajouterons la prise en charge des pages introuvables. Cela ne devrait pas se produire dans la plupart des systèmes de production, mais il n'est pas rare que l'emplacement du script de test change ou que le programmeur entre une mauvaise URL. Si vous pouvez signaler les erreurs 404 naturellement, vous pouvez fournir davantage d’aide aux utilisateurs et programmeurs frustrés. Par exemple, si un script sur le serveur est supprimé, nous pouvons utiliser le code du listing 7 pour que l'utilisateur voie une erreur non descriptive comme celle illustrée dans la figure 5.

Cas extrêmes et situations difficiles

À ce stade, certains programmeurs débutants peuvent se demander de quoi il s'agit. Voici un fait que vous devez savoir : moins de 5 % des requêtes Ajax utilisent des états prêts tels que 2 et 3 et des codes d'état tels que 403 (en fait, ce taux est probablement plus proche de 1 %, voire moins). Ces situations sont très importantes et sont appelées cas extrêmes : elles ne se produisent que dans des situations très spécifiques où se posent les problèmes les plus exotiques. Bien que ces situations ne soient pas courantes, ces cas extrêmes représentent 80 % des problèmes rencontrés par la plupart des utilisateurs.

Pour l'utilisateur type, le fait que l'application fonctionne correctement 100 fois est généralement oublié, mais une erreur dans l'application sera clairement mémorisée par ! eux. Si vous pouvez bien gérer les cas extrêmes (ou les situations difficiles), vous pouvez offrir des récompenses satisfaisantes aux utilisateurs qui reviennent sur votre site.

Figure 5. Gestion des erreurs courantes

L'utilisateur n'a aucun moyen de savoir si le problème est un problème d'authentification, un script introuvable (comme c'est le cas ici), une erreur de l'utilisateur ou autre chose dans le code. L'ajout d'un code simple peut rendre cette erreur plus spécifique. Veuillez vous référer au Listing 8, qui est responsable de la gestion de la situation dans laquelle le script n'est pas trouvé ou où une erreur d'authentification se produit, et des messages spécifiques seront émis lorsque ces erreurs se produisent.

Listing 8. Vérification des codes d'état valides

Bien que cela soit encore assez simple, cela fournit des informations un peu plus utiles. La figure 6 montre la même erreur que la figure 5, mais cette fois, le code de gestion des erreurs explique mieux à l'utilisateur ou au programmeur ce qui s'est exactement passé.

Figure 6. Gestion spéciale des erreurs

Dans notre propre application, nous pourrions envisager d'effacer le nom d'utilisateur et le mot de passe et d'ajouter un message d'erreur à l'écran en cas d'échec d'authentification. Nous pouvons utiliser une approche similaire pour mieux gérer le script introuvable ou d'autres erreurs de type 400 (par exemple, 405 signifie qu'une méthode de requête inacceptable telle que l'envoi d'une requête HEAD n'est pas autorisée, et 407 signifie qu'une authentification proxy est requise). Cependant, quelle que soit l'option que vous choisissez, vous devez commencer à traiter le code d'état renvoyé par le serveur.

Autres types de requêtes

Si vous souhaitez réellement contrôler l'objet XMLHttpRequest, envisagez d'implémenter cette dernière fonctionnalité en ajoutant la requête HEAD à la directive. Dans les deux articles précédents, nous avons présenté comment générer des requêtes GET ; dans un prochain article, vous découvrirez comment utiliser les requêtes POST pour envoyer des données au serveur. Cependant, dans un esprit d'amélioration de la gestion des erreurs et de la collecte d'informations, vous devez apprendre à générer des requêtes HEAD.

Faire la requête

Faire la requête HEAD est en fait très simple ; vous appelez la méthode open() avec "HEAD" (au lieu de "GET" ou "POST") comme premier paramètre, comme indiqué dans le Listing 9.

Listing 9. Utiliser Ajax pour générer une

fonction de requête HEAD getSalesData() {
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Lorsque vous générez une requête HEAD comme celle-ci, le serveur ne renvoie pas de réponse réelle comme il le ferait pour une requête GET ou POST. Au lieu de cela, le serveur renvoie uniquement l'en-tête de la ressource, qui indique la date à laquelle le contenu de la réponse a été modifié pour la dernière fois, si la ressource demandée existe et de nombreuses autres informations utiles. Vous pouvez utiliser ces informations pour en savoir plus sur la ressource avant qu'elle ne soit traitée et renvoyée par le serveur.

La chose la plus simple que vous puissiez faire pour ce type de requête est simplement d'afficher le contenu de tous les en-têtes de réponse. Cela vous donne une idée de ce qui est disponible via la requête HEAD. Le listing 10 fournit une fonction de rappel simple qui imprime le contenu de l'en-tête de réponse obtenu à partir de la requête HEAD.

Listing 10. Afficher le contenu de l'en-tête de réponse obtenu à partir de la

fonction de requête HEAD updatePage() {
si (request.readyState == 4) {
alert(request.getAllResponseHeaders());
}
}

Voir la figure 7, qui montre les en-têtes de réponse renvoyés par une simple application Ajax qui envoie une requête HEAD au serveur.

Vous pouvez utiliser ces en-têtes individuellement (du type de serveur au type de contenu) pour fournir des informations ou des fonctionnalités supplémentaires dans votre application Ajax.

Vérification de l'URL

Vous avez vu comment vérifier les erreurs 404 lorsque l'URL n'existe pas. Si cela s'avère être un problème courant - peut-être qu'un script ou un servlet particulier est manquant - vous souhaiterez peut-être vérifier l'URL avant de faire une requête GET ou POST complète. Pour implémenter cette fonctionnalité, générez une requête HEAD, puis recherchez les erreurs 404 dans la fonction de rappel. Le listing 11 montre une fonction de rappel simple ;

Listing 11. Vérifier si une URL existe

Honnêtement, la valeur de ce code n'est pas si grande. Le serveur doit répondre à la demande et construire une réponse pour compléter l'en-tête de réponse Content-Length, afin qu'aucun temps de traitement ne soit économisé. De plus, cela prend autant de temps que générer la requête et utiliser une requête HEAD pour voir si l'URL existe, car cela génère la requête en utilisant GET ou POST plutôt que de simplement gérer le code d'erreur comme indiqué dans le listing 7. Cependant, il est parfois utile de savoir exactement ce qui est actuellement disponible ; on ne sait jamais quand votre créativité entrera en jeu ou quand vous aurez besoin d'une requête HEAD !

Requêtes HEAD utiles

Un domaine dans lequel la requête HEAD peut être très utile est de voir la longueur du contenu ou le type de contenu. Cela peut déterminer si une grande quantité de données doit être renvoyée pour traiter la requête et si le serveur essaie de renvoyer des données binaires au lieu de HTML, de texte ou de XML (les trois types de données sont plus faciles à traiter en JavaScript qu'en Javascript). données binaires).

Dans ces cas, il vous suffit d'utiliser le nom d'en-tête approprié et de le transmettre à la méthode getResponseHeader() de l'objet XMLHttpRequest. Donc, pour obtenir la longueur de la réponse, appelez simplement request.getResponseHeader("Content-Length");. Pour obtenir le type de contenu, utilisez request.getResponseHeader("Content-Type");.

Dans de nombreuses applications, générer une requête HEAD n'ajoute aucune fonctionnalité et peut même ralentir la requête (en forçant une requête HEAD à obtenir des données sur la réponse, puis en utilisant une requête GET ou POST pour obtenir réellement la réponse). Cependant, dans les situations où vous n'êtes pas sûr d'un script ou d'un composant côté serveur, l'utilisation d'une requête HEAD peut obtenir des données de base sans réellement traiter les données de réponse ni nécessiter beaucoup de bande passante pour envoyer la réponse.

Conclusion

Pour de nombreux programmeurs Ajax et Web, le matériel présenté dans cet article peut sembler trop avancé. Quel est l’intérêt de générer une requête HEAD ? Quand devez-vous gérer explicitement les codes de statut de redirection en JavaScript ? Ce sont de bonnes questions ; pour des applications simples, la réponse est que la valeur de ces techniques avancées n’est pas très grande.

Cependant, le Web n'est plus un endroit où il suffit d'implémenter des applications simples ; les utilisateurs sont devenus plus avancés, les clients attendent une meilleure stabilité, des rapports d'erreurs plus avancés, et si une application est en panne 1 % du temps, le gestionnaire pourrait alors être viré pour cela.

Par conséquent, votre travail ne peut pas se limiter à des applications simples, mais nécessite une compréhension plus approfondie de XMLHttpRequest.

·Si vous pouvez réfléchir aux différents états de préparation et comprendre comment ces états de préparation diffèrent entre les navigateurs, vous pouvez rapidement déboguer votre application. Vous pouvez même développer des fonctionnalités créatives basées sur l'état de préparation et signaler l'état demandé aux utilisateurs et aux clients.
·Si vous souhaitez contrôler les codes d'état, vous pouvez configurer votre application pour gérer les erreurs de script, les réponses inattendues et les cas extrêmes. Le résultat est une application qui fonctionne correctement à tout moment, pas seulement lorsque tout va bien.
·Ajoutez la possibilité de générer des requêtes HEAD, de vérifier si une URL existe et de confirmer si un fichier a été modifié, afin de garantir que les utilisateurs peuvent obtenir des pages valides et que les informations qu'ils voient sont les dernières (surtout) les surprennent. à quel point cette application est robuste et polyvalente.
Le but de cet article n'est pas de donner à votre application un aspect sophistiqué, mais de vous aider à supprimer le projecteur jaune et à mettre en valeur la beauté du texte, ou à ressembler davantage à un ordinateur de bureau. Bien que ce soient toutes des fonctionnalités d’Ajax (qui seront abordées dans les prochains articles), elles sont comme une couche de crème sur le gâteau. Si vous pouvez utiliser Ajax pour construire une base solide afin que votre application puisse bien gérer les erreurs et les problèmes, les utilisateurs reviendront sur votre site et votre application. Dans le prochain article, nous ajouterons cette technique intuitive qui fera trembler d’enthousiasme vos clients. (Sérieusement, vous ne voulez pas manquer le prochain article !)