Comment effacer les en-têtes HTTP pour les appels AJAX GET?

Question

J'ai développé une solution qui repose sur un appel AJAX pour récupérer des informations et mettre à jour la page du client toutes les 10 secondes. Cela fonctionne bien, mais je suis préoccupé par l’évolutivité du code, compte tenu du nombre et de la longueur des en-têtes transmis du client au serveur et inversement. J'ai supprimé un certain nombre d'en-têtes redondants côté serveur, principalement liés à ASP.NET, et j'essaie maintenant de réduire le nombre d'en-têtes provenant du client.

Le navigateur utilisé par mon entreprise est IE (version 6, qui passera bientôt à la version 7). Ceci est une approximation de mon code actuel:

var xmlHTTP = new ActiveXObject('Microsoft.XMLHTTP');

xmlHTTP.onreadystatechange = function() {
    if ((xmlHTTP.readyState == 4) && (xmlHTTP.status == 200)) {
        myCallbackFunction(xmlHTTP);
    }
};

xmlHTTP.open('GET', 'myUrl.aspx');

try {
    xmlHTTP.setRequestHeader("User-Agent", ".");
    xmlHTTP.setRequestHeader("Accept", ".");
    xmlHTTP.setRequestHeader("Accept-Language", ".");
    xmlHTTP.setRequestHeader("Content-Type", ".");
} catch(e) {}

xmlHTTP.send();

Bien que j'ai lu qu'il était possible d'effacer ces en-têtes, je n'ont pas trouvé de moyen de le faire qui fonctionne dans IE6. Si vous les définissez comme nulles, vous obtiendrez une exception d'incompatibilité de type. J'ai donc fini par les remplacer par ".". pour le moment. Existe-t-il un autre moyen de les effacer ou une autre méthode pour réduire les en-têtes HTTP soumis?

De plus, il semble n'y avoir aucun moyen de remplacer ou de raccourcir l'en-tête "Référent".

Answer 1

Selon les spécifications WD

.

  

La méthode setRequestHeader () ajoute une valeur si l'en-tête HTTP indiqué en tant qu'argument fait déjà partie de la liste des en-têtes de requête.

Autrement dit, vous pouvez uniquement ajouter des en-têtes, pas les remplacer.

Cela ne correspond pas tout à fait au comportement actuel du navigateur, mais cela peut également indiquer l’orientation des navigateurs. Dans ce cas, les efforts déployés sur ce front sont une perte de temps à long terme. Dans tous les cas, le comportement actuel du navigateur avec les en-têtes de réglage est très varié et on ne peut généralement pas s'y fier.

  

Il semble n'y avoir aucun moyen de remplacer ou de raccourcir l'en-tête "Référent".

Cela ne me surprendrait pas, étant donné que certaines personnes utilisent à tort «Referer» [sic] comme mécanisme de contrôle d'accès.

Vous pouvez essayer de vous assurer que l'URL de la page en cours n'est pas excessivement longue, mais pour être honnête, tout cela me semble être une optimisation prématurée. Quoi que vous fassiez, votre demande tiendra dans un paquet IP, il n’y aura donc pas une différence de performance visible.

Cela vaut peut-être la peine pour Mibbit (comme mentionné sur le blog que vous avez lié) d'essayer ce genre de choses, car Mibbit génère un trafic assez impressionnant, mais pour une simple application à l'échelle de l'entreprise, je ne pense pas que le multi-navigateur -and-proxy-testing-load: le rapport qualité-prix pour les utilisateurs finaux en vaut la peine.

Answer 2

IE 6 et les versions antérieures utilisent l’ActiveXObject créé à partir de MSXML.XMLHTTP (dérivé de IXMLHTTPRequest ), alors que IE 7 et d'autres navigateurs modernes tels que Mozilla utilisent un objet intrinsèque appelé XmlHttpRequest . C'est probablement la raison pour laquelle vous ne pouvez pas définir les en-têtes de demande sur null pour l'implémentation MSXML, mais vous pouvez le faire pour l'objet intégré.

Par conséquent, je ne crois pas qu’il soit possible de vider collectivement tous les en-têtes. Le lien vers Mibbit que vous présentez fournit uniquement une fonction permettant de définir tous les en-têtes sur null un par un. Dans des scénarios normaux, réduire les en-têtes peut s'avérer très insignifiant pour réduire la charge de trafic.

Cela étant dit, je suis curieux de savoir pourquoi vous définissez les en-têtes de requête sur "."; plutôt que sur une chaîne vide "" .

Answer 3

Je m'abstiendrais de ce type de micro-optimisations et chercherais plutôt un modèle push. En guise de lieu de départ:

• Flash peut créer des sockets persistants et gérer les événements en javascript.
• Vous pouvez implémenter des flux bidirectionnels sur HTTP synchrone (BOSH). Voir http://xmpp.org/extensions/xep-0124.html

Ces deux éléments sont généralement associés à un serveur XMPP sur le back-end.