¿Cómo puedo borrar los encabezados HTTP para las llamadas AJAX GET?

Question

He desarrollado una solución que se basa en una llamada AJAX para recuperar información y actualizar la página del cliente cada 10 segundos. Esto funciona bien, pero me preocupa la escalabilidad del código, dado el número y la longitud de los encabezados que se pasan del cliente al servidor y nuevamente. He eliminado varios encabezados redundantes en el lado del servidor, principalmente relacionados con ASP.NET, y ahora estoy intentando reducir los encabezados que vienen del cliente.

El navegador utilizado por mi empresa es IE (versión 6, que se actualizará pronto a 7). Esta es una aproximación de mi código actual:

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();

Aunque He leído que es posible borrar algunos de estos encabezados, No he encontrado una forma de hacerlo que funcione en IE6. Al establecerlos en nulos, se obtiene una excepción de Desajuste de tipo, por lo que terminé simplemente reemplazándolos con '.' Siendo por el momento. ¿Hay alguna otra forma de eliminarlos o un método alternativo para reducir los encabezados HTTP enviados?

Además, parece que no hay forma de reemplazar o acortar el encabezado 'Referrer' en absoluto.

Answer 1

De acuerdo con la WD spec

  

El método setRequestHeader () agrega un valor si el encabezado HTTP dado como argumento ya es parte de la lista de encabezados de solicitud.

Es decir, solo puedes agregar encabezados, no reemplazarlos.

Esto no coincide completamente con el comportamiento actual del navegador, pero puede ser hacia donde se dirigirán los navegadores, en cuyo caso cualquier esfuerzo en este frente es una pérdida de tiempo a largo plazo. En cualquier caso, el comportamiento actual del navegador con los encabezados de configuración es muy variado y generalmente no se puede confiar en él.

  

Parece que no hay manera de reemplazar o acortar el encabezado 'Referrer' en absoluto.

Eso no me sorprendería, dado que algunas personas usan erróneamente & # 8216; Referer & # 8217; [sic] como un mecanismo de control de acceso.

Puede intentar asegurarse de que la URL de la página actual no sea excesivamente larga, pero para ser sincero, todo esto me huele a optimización prematura. Independientemente de lo que haga, su solicitud encajará dentro de un paquete IP, por lo que no quedará una gran diferencia de rendimiento visible.

Puede que valga la pena que Mibbit (como se menciona en el blog que has vinculado) intente esto, porque Mibbit atrae una cantidad de tráfico bastante asombrosa, pero para una aplicación sencilla de toda la empresa no creo que el navegador cruzado -y-proxy-testing-charge: la relación beneficio-usuario final de jugar con los encabezados vale la pena.

Answer 2

IE 6 y versiones anteriores usan ActiveXObject creado desde MSXML.XMLHTTP (en realidad deriva de IXMLHTTPRequest ), mientras que IE 7 y otros navegadores modernos como Mozilla usan un objeto intrínseco llamado XmlHttpRequest . Esta es probablemente la razón por la que no puede configurar los encabezados de solicitud en null para la implementación de MSXML, pero sí para el objeto incorporado.

Por lo tanto, no creo que haya ninguna forma de borrar todos los encabezados de forma colectiva. El enlace a Mibbit que presenta solo proporciona una función para configurar todos los encabezados en nulo uno por uno. Para los escenarios normales, reducir los encabezados puede resultar muy insignificante para reducir la carga de tráfico.

Dicho esto, tengo curiosidad por saber por qué está configurando los encabezados de solicitud en ". " en lugar de una cadena vacía " " .

Answer 3

Yo renunciaría a este tipo de micro-optimizaciones y buscaría un modelo push en su lugar. A modo de punto de partida:

• Flash puede crear sockets persistentes e intermediar los eventos en javascript.
• Puede implementar secuencias bidireccionales a través de HTTP síncrono (BOSH). Consulte http://xmpp.org/extensions/xep-0124.html

En general, ambos están emparejados con un servidor XMPP en el servidor.