Para muchos desarrolladores web, generar solicitudes simples y recibir respuestas simples es suficiente, pero para los desarrolladores que desean dominar Ajax, es necesaria una comprensión completa de los códigos de estado HTTP, los estados listos y el objeto XMLHttpRequest. En este artículo, Brett McLaughlin le presenta los distintos códigos de estado y le muestra cómo los manejan los navegadores. También analiza algunas de las solicitudes HTTP menos comunes utilizadas en Ajax.
En el artículo anterior de esta serie, analizamos más de cerca el objeto XMLHttpRequest, que es la pieza central de una aplicación Ajax y es responsable de manejar las solicitudes de las aplicaciones y scripts del lado del servidor y procesar los datos devueltos por los componentes del lado del servidor. Dado que todas las aplicaciones Ajax utilizan el objeto XMLHttpRequest, es posible que desee familiarizarse con este objeto para que Ajax pueda funcionar mejor.
En este artículo, me centraré en las tres partes clave de este objeto de solicitud según el artículo anterior:
· Estado de preparación HTTP · Código de estado HTTP · Los tipos de solicitud que se pueden generarEstas tres partes son factores a considerar en la construcción
.
al solicitarlo; sin embargo, se ha escrito muy poco sobre estos temas. Sin embargo, si desea aprender algo más que los conceptos básicos de la programación Ajax, deberá familiarizarse con el contenido de los estados listos, los códigos de estado y las solicitudes mismas. Cuando algo sale mal con su aplicación (y siempre sucede), si comprende correctamente el estado de preparación, cómo generar una solicitud HEAD o qué significa exactamente un código de estado 400, puede depurar el problema en 5 minutos en lugar de 5 horas invertidas. en diversas frustraciones y confusiones.
Primero veamos el estado de HTTP listo.
Una mirada más cercana al estado preparado de HTTP
Recordarás del artículo anterior que el objeto XMLHttpRequest tiene una propiedad llamada readyState. Este atributo garantiza que el servidor haya completado una solicitud, normalmente utilizando una función de devolución de llamada para leer datos del servidor y actualizar el contenido del formulario o página web. El Listado 1 muestra un ejemplo simple (también es un ejemplo del artículo anterior de esta serie; consulte Recursos).
XMLHttpRequest o XMLHttp: un cambio de nombre
Microsoft™ e Internet Explorer utilizan un objeto llamado XMLHttp en lugar del objeto XMLHttpRequest, que utilizan Mozilla, Opera, Safari y la mayoría de los navegadores que no son de Microsoft. Para simplificar, llamaré a ambos objetos simplemente XMLHttpRequest. Esto es coherente tanto con lo que vemos en la Web como con la intención de Microsoft de utilizar XMLHttpRequest como objeto de solicitud en Internet Explorer 7.0. (Consulte la Parte 2 para obtener más información sobre este tema).
Listado 1. Manejo de la respuesta del servidor en una
función de devolución de llamada updatePage() {
si (solicitud.readyState == 4) {
si (solicitud.estado == 200) {
var respuesta = request.responseText.split("|");
document.getElementById("pedido").valor = respuesta[0];
document.getElementById("dirección").innerHTML =
respuesta[1].replace(/n/g, "<br />");
} demás
alert("el estado es " + request.status);
}
}
Este es obviamente el uso más común (y más simple) del estado listo. Como puede ver por el número "4", hay varios otros estados listos (también vio esta lista en el artículo anterior; consulte Recursos):
· 0: la solicitud no está inicializada (aún no se ha llamado a open()) .
·1: La solicitud se ha establecido, pero no se ha enviado (aún no se ha llamado a send()).
·2: La solicitud ha sido enviada y está siendo procesada (normalmente ahora se pueden obtener los encabezados de contenido de la respuesta).
·3: La solicitud se está procesando; normalmente hay algunos datos disponibles en la respuesta, pero el servidor aún no ha terminado de generar la respuesta.
·4: La respuesta está completa; puedes obtener y utilizar la respuesta del servidor.
Si desea comprender más que los conceptos básicos de la programación Ajax, necesita conocer no solo estos estados, sino también cuándo ocurren y cómo usarlos. Primero, debe saber qué estados de solicitud puede encontrar en cada estado de preparación. Desafortunadamente, esto no es intuitivo y implica varios casos especiales.
Estado listo oculto
El primer estado listo se caracteriza porque el atributo readyState es 0 (readyState == 0), lo que indica un estado no inicializado. Esta propiedad se establece en 1 una vez que se llama a open() en el objeto de solicitud. Dado que normalmente llama a open() inmediatamente después de inicializar un par de solicitudes, rara vez verá un estado readyState == 0. Además, el estado listo no inicializado no tiene ningún uso real en aplicaciones reales.
Pero para nuestro interés, consulte el Listado 2, que muestra cómo obtener este estado listo cuando readyState se establece en 0.
Listado 2. Obteniendo el estado 0 listo
función obtenerDatosVentas() {
//Crear un objeto de solicitud
crearSolicitud();
alert("El estado listo es: " + request.readyState
// Configurar (inicializar) la solicitud
);
var url = "/boards/servlet/UpdateBoardSales";
request.open("OBTENER", url, verdadero);
request.onreadystatechange = actualizarPágina;
solicitud.enviar (nulo);
}
En este ejemplo simple, getSalesData() es la función que llama la página web para iniciar una solicitud (como cuando se hace clic en un botón). Tenga en cuenta que debe verificar el estado listo antes de llamar a open(). La Figura 1 muestra los resultados de ejecutar esta aplicación.
Figura 1. Estado listo 0
Obviamente esto no le compra mucho; hay muy pocas situaciones en las que necesita asegurarse de que la función open() no haya sido llamada todavía. En el mundo real de la mayoría de la programación Ajax, el único uso de este estado listo es usar el mismo objeto XMLHttpRequest para generar múltiples solicitudes en múltiples funciones. En este caso (poco común), es posible que desee asegurarse de que el objeto de solicitud esté en un estado no inicializado (readyState == 0) antes de generar una nueva solicitud. Básicamente, esto garantiza que otra función no esté utilizando el objeto al mismo tiempo.
Ver el estado de preparación de la solicitud que se está procesando
. Además del estado listo 0, el objeto de solicitud también necesita pasar por varios otros estados listos de solicitudes y respuestas típicas, y finalmente termina en el estado listo 4. Es por eso que ve la línea if (request.readyState == 4) en la mayoría de las funciones de devolución de llamada, asegura que el servidor ha terminado de procesar la solicitud y ahora es seguro actualizar la página web o actualizar la página según la solicitud devuelta; del servidor para realizar operaciones.
Es muy sencillo ver cómo se produce este estado. Si el estado listo es 4, no solo tenemos que ejecutar el código en la función de devolución de llamada, sino que también imprimimos el estado listo cada vez que se llama a la función de devolución de llamada. El Listado 3 ofrece un ejemplo de implementación de esta funcionalidad.
Cuando 0 es igual a 4
, debe verificar el estado listo 0 para asegurarse de que el objeto de solicitud no esté en uso cuando varias funciones de JavaScript usan el mismo objeto de solicitud. Este mecanismo puede causar problemas. Dado que readyState == 4 representa una solicitud completa, a menudo encontrará que los objetos de solicitud en el estado listo que no se están utilizando actualmente todavía están configurados en 4; esto se debe a que los datos devueltos por el servidor ya se han utilizado, pero no. Se han realizado cambios desde que se configuraron en el estado listo. Existe una función abort() que restablece el objeto de solicitud, pero esta función realmente no se utiliza para este propósito. Si debe utilizar varias funciones, es mejor crear y utilizar una función para cada función en lugar de compartir el mismo objeto entre varias funciones.
Listado 3. Ver
función de preparación updatePage() {
// Muestra el estado listo actual
alert("updatePage() llamado con el estado listo de " + request.readyState);
}
Si no está seguro de cómo ejecutar esta función, necesita crear una función, luego llamar a esta función en la página web y hacer que envíe una solicitud al componente del lado del servidor (como la función que se muestra en el Listado 2, o la función en esta serie de artículos) Ejemplos dados en la Parte 1 y Parte 2). Asegúrese de configurar la función de devolución de llamada en updatePage() al realizar la solicitud. Para hacer esto, establezca la propiedad onreadystatechange del objeto de solicitud en updatePage().
Este código es una demostración exacta del significado de onreadystatechange: cada vez que cambia el estado listo de la solicitud, se llama a updatePage() y luego podemos ver una advertencia. La Figura 2 muestra un ejemplo de cómo llamar a esta función, donde el estado listo es 1.
Figura 2. Estado listo 1
Puede intentar ejecutar este código usted mismo. Colóquelo en una página web y active el controlador de eventos (haga clic en un botón, tabule entre campos o use cualquier método que establezca para activar la solicitud). Esta función de devolución de llamada se ejecutará varias veces (cada vez que cambie el estado listo) y podrá ver la advertencia para cada estado listo. Esta es la mejor manera de realizar un seguimiento de las distintas etapas por las que pasa una solicitud.
Inconsistencias del navegador
Una vez que tenga una comprensión básica del proceso, intente acceder a su página desde algunos navegadores diferentes. Debería notar que los navegadores son inconsistentes en la forma en que manejan estos estados listos. Por ejemplo, en Firefox 1.5, verás los siguientes estados listos:
·1
·2
·3
·4
Esto no es sorprendente ya que aquí se representa el estado de cada solicitud. Sin embargo, si usas Safari para acceder a la misma aplicación, deberías ver, o no, algo interesante. Así es como se ve en Safari 2.0.1:
·2
·3
·4
Safari en realidad descarta el primer estado listo, y no hay ninguna razón obvia para ello, pero así es como funciona Safari. Esto también ilustra un punto importante: si bien es una buena idea asegurarse de que el estado de la solicitud sea 4 antes de usar los datos en el servidor, el código escrito para depender de cada estado listo para la transición se verá diferente en diferentes navegadores.
Por ejemplo, cuando se utiliza Opera 8.5, el estado de preparación mostrado es aún peor:
·3
·
4Finalmente, Internet Explorer mostrará el siguiente estado:
·1
·2
·3
·4Si
tiene problemas con sus solicitudes, este es el primer lugar al que acudir para identificar el problema. La mejor manera es probar esto tanto en Internet Explorer como en Firefox: verá los 4 estados y podrá verificar en qué se encuentra cada estado de la solicitud.
A continuación, echemos un vistazo a la situación desde el punto de vista de la respuesta.
Datos de respuesta bajo el microscopio
Una vez que entendemos los diversos estados de preparación que ocurren durante el proceso de solicitud, es hora de observar otro aspecto del objeto XMLHttpRequest: el atributo ResponseText. Recuerde lo que presentamos en el artículo anterior, puede saber que este atributo se utiliza para obtener datos del servidor. Una vez que el servidor ha terminado de procesar la solicitud, puede colocar cualquier dato necesario para responder a la solicitud en el texto de respuesta de la solicitud. La función de devolución de llamada puede luego usar estos datos, como se muestra en el Listado 1 y el Listado 4.
Listado 4. Usando la respuesta devuelta en el servidor
función actualizarPágina() {
si (solicitud.readyState == 4) {
var nuevoTotal = solicitud.respuestaTexto;
var totalSoldEl = document.getElementById("total-vendido");
var netProfitEl = document.getElementById("beneficio neto");
replaceText(totalSoldEl, newTotal);
/* Representa la nueva ganancia neta */
var boardCostEl = document.getElementById("costo de la placa");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("costo-hombre");
var costohombre = getText(costohombreEl);
var beneficioPorTablero = CostoTablero - CostoMan;
var netProfit = beneficioPerBoard * newTotal
/* Actualizar el beneficio neto en el formulario de ventas */
beneficio neto = Math.round(beneficio neto * 100) / 100;
reemplazarTexto(netProfitEl, netProfit);
El Listado
1 es bastante simple; el Listado 4 es un poco más complicado, pero ambos verifican el estado listo al principio y obtienen el valor de la propiedad ResponseText.
Ver el texto de respuesta de una solicitud
De manera similar al estado listo, el valor de la propiedad texto de respuesta también cambia a lo largo de la vida de la solicitud. Para ver este cambio, utilice el código que se muestra en el Listado 5 para probar el texto de respuesta de la solicitud, así como su estado de preparación.
Listado 5. Probando la función de propiedad ResponseText
updatePage() {
// Muestra el estado listo actual
alert("updatePage() llamado con estado listo de " + request.readyState +
" y un texto de respuesta de '" + request.responseText + "'");
}
Ahora abra la aplicación web en su navegador y active su solicitud. Para ver mejor el efecto de este código, utilice Firefox o Internet Explorer, ya que ambos navegadores pueden informar todos los estados de preparación posibles durante la solicitud. Por ejemplo, en el estado listo 2, el texto de respuesta no está definido (consulte la Figura 3); si la consola de JavaScript también está abierta, verá un error.
Figura 3. Texto de respuesta para el estado listo 2
Sin embargo, en el estado listo 3, el servidor ha puesto un valor en la propiedad ResponseText, al menos en este ejemplo (consulte la Figura 4).
Figura 4. Texto de respuesta para el estado listo 3
Verás que la respuesta con un estado listo de 3 es diferente en cada script, cada servidor e incluso cada navegador. Sin embargo, esto sigue siendo muy útil para depurar aplicaciones.
Obtención de datos seguros
Todos los documentos y especificaciones enfatizan que los datos solo se pueden usar de manera segura cuando el estado de preparación es 4. Créame, cuando el estado listo es 3, rara vez encontrará una situación en la que no pueda obtener datos de la propiedad ResponseText. Sin embargo, no es una buena idea hacer que la lógica de su aplicación dependa del estado listo 3: una vez que escribe código que se basa en datos completos en el estado listo 3, es casi responsable de los datos incompletos en ese momento.
Un mejor enfoque es proporcionar información al usuario de que cuando esté en el estado listo 3, la respuesta será pronto. Aunque usar funciones como alert() es obviamente una mala idea (usar Ajax y luego bloquear al usuario con un cuadro de diálogo de alerta es obviamente incorrecto), puede actualizar los campos en un formulario o página cuando cambia el estado listo. Por ejemplo, para el estado listo 1, establezca el ancho del indicador de progreso en 25 %, para el estado listo 2, establezca el ancho del indicador de progreso en 50 % y para el estado listo 3, establezca el ancho del indicador de progreso en 25 % El ancho se establece en 75% y cuando el estado listo es 4, el ancho del indicador de progreso se establece en 100% (completo).
Por supuesto, como ya has visto, este método es muy inteligente, pero depende del navegador. En Opera nunca ves los dos primeros estados listos y en Safari no hay el primero (1). Por esta razón dejé este código como ejercicio y no lo incluí en este artículo.
Ahora es el momento de mirar los códigos de estado.
Una mirada más profunda a los códigos de estado HTTP
Con el estado listo y la respuesta del servidor que aprendió en Técnicas de programación Ajax, puede agregar otro nivel de complejidad a sus aplicaciones Ajax: usando códigos de estado HTTP. No hay nada nuevo sobre Ajax en este código. Han existido desde los albores de la Web. Es posible que haya visto varios códigos de estado en los navegadores web:
· 401: No autorizado · 403: Prohibido · 404: No encontrado
Puede encontrar más códigos de estado (consulte Recursos para obtener una lista completa). Para agregar una capa adicional de mecanismos de control y respuesta (y un manejo de errores más sólido) a sus aplicaciones Ajax, necesita ver correctamente los códigos de estado en las solicitudes y respuestas.
200: Todo está bien
En muchas aplicaciones Ajax, verá una función de devolución de llamada que es responsable de verificar el estado de preparación y luego continuar utilizando los datos devueltos por la respuesta del servidor, como se muestra en el Listado 6.
Listado 6. Función de devolución de llamada que ignora
la función del código de estado updatePage() {
si (solicitud.readyState == 4) {
var respuesta = request.responseText.split("|");
document.getElementById("pedido").valor = respuesta[0];
document.getElementById("dirección").innerHTML =
respuesta[1].replace(/n/g, "<br />");
}
}
Esto resulta ser un enfoque incorrecto y miope de la programación Ajax. Si el script requiere autenticación y la solicitud no proporciona un certificado válido, el servidor devuelve un código de error como 403 o 401. Sin embargo, debido a que el servidor respondió a la solicitud, el estado listo se establece en 4 (aunque la respuesta no fue la esperada por la solicitud). En última instancia, el usuario no obtiene datos válidos y pueden ocurrir errores graves cuando JavaScript intenta utilizar datos del servidor que no existen.
Se necesita un esfuerzo mínimo para garantizar que el servidor no solo complete una solicitud, sino que también devuelva un código de estado "todo bien". Este código es "200", que se informa a través del atributo de estado del objeto XMLHttpRequest. Para asegurarse de que el servidor no solo complete una solicitud sino que también informe un estado correcto, agregue otra verificación a su función de devolución de llamada, como se muestra en el Listado 7.
Listado 7. Comprobar códigos de estado válidos
function updatePage() {
si (solicitud.readyState == 4) {
si (solicitud.estado == 200) {
var respuesta = request.responseText.split("|");
document.getElementById("pedido").valor = respuesta[0];
document.getElementById("dirección").innerHTML =
respuesta[1].replace(/n/g, "<br />");
} demás
alert("el estado es " + request.status);
}
}
Al agregar estas pocas líneas de código, puede confirmar si hay un problema y el usuario verá un mensaje de error útil en lugar de simplemente ver una página compuesta de datos sacados de contexto sin explicación.
Redirecciones y redirecciones
Antes de entrar en detalles sobre los errores, vale la pena discutir un tema del que no necesita preocuparse al usar Ajax: las redirecciones. Entre los códigos de estado HTTP, esta es la serie 300 de códigos de estado, que incluyen:
301: Movido permanentemente 302: Encontrado (solicitud redirigida a otra URL/URI)
·305: Uso de un proxy (la solicitud debe utilizar un proxy para acceder al recurso solicitado)
Los programadores de Ajax pueden no estar demasiado preocupados por los problemas de redirección, por dos razones:
·Primero, las aplicaciones Ajax generalmente están diseñadas para un servidor específico. script, servlet o aplicación. Los programadores de Ajax no tienen tan claro los componentes que desaparecen sin que usted los vea. Entonces, a veces sabes que el recurso se ha movido (porque lo moviste o lo moviste de alguna manera), y luego modificas la URL en la solicitud y nunca vuelves a encontrar este resultado.
Una razón más importante es que las aplicaciones y solicitudes de Ajax están encapsuladas en un entorno limitado. Esto significa que el dominio que sirve las páginas web que generan solicitudes Ajax debe ser el dominio que responde a esas solicitudes. Por lo tanto, la página web proporcionada por ebay.com no puede realizar una solicitud de estilo Ajax a un script que se ejecuta en amazon.com; una aplicación Ajax en ibm.com no puede realizar una solicitud a servlets que se ejecutan en netbeans.org.
·El resultado es que su solicitud no puede ser redirigida a otro servidor sin generar un error de seguridad. En estos casos, no recibirá ningún código de estado. Normalmente se genera un error de JavaScript en la consola de depuración. Por lo tanto, después de pensar lo suficiente en los códigos de estado, puede ignorar por completo el problema de los códigos de redireccionamiento.
El resultado es que su solicitud no puede redirigirse a otro servidor sin generar un error de seguridad. En estos casos, no recibirá ningún código de estado. Normalmente se genera un error de JavaScript en la consola de depuración. Por lo tanto, después de pensar lo suficiente en los códigos de estado, puede ignorar por completo el problema de los códigos de redireccionamiento.
Errores
Una vez que reciba el código de estado 200 y se dé cuenta de que puede ignorar en gran medida los códigos de estado de la serie 300, el único conjunto de códigos del que debe preocuparse son los códigos de la serie 400, que ilustran los diferentes tipos de errores. Mire nuevamente el Listado 7 y observe que cuando se manejan errores, solo se envían al usuario unos pocos mensajes de error comunes. Aunque este es un paso en la dirección correcta, estos mensajes todavía no son muy útiles para decirles a los usuarios y programadores que trabajan en la aplicación qué es exactamente lo que está fallando.
Primero, agregaremos soporte para páginas no encontradas. En realidad, esto no debería suceder en la mayoría de los sistemas de producción, pero no es raro que la ubicación del script de prueba cambie o el programador ingrese la URL incorrecta. Si puede informar los errores 404 de forma natural, podrá brindar más ayuda a los usuarios y programadores frustrados. Por ejemplo, si se elimina un script en el servidor, podemos usar el código del Listado 7 para que el usuario vea un error no descriptivo como el que se muestra en la Figura 5.
Casos extremos y situaciones difíciles
Llegados a este punto, algunos programadores novatos pueden preguntarse de qué se trata esto. Aquí hay un hecho que necesita saber: menos del 5% de las solicitudes de Ajax utilizan estados listos como 2 y 3 y códigos de estado como 403 (en realidad, esta tasa probablemente esté más cerca del 1% o incluso menos). Estas situaciones son muy importantes y se denominan casos extremos: sólo ocurren en situaciones muy específicas donde se encuentran los problemas más exóticos. Aunque estas situaciones no son comunes, estos casos extremos representan el 80% de los problemas que encuentran la mayoría de los usuarios.
Para el usuario típico, el hecho de que la aplicación funciona correctamente 100 veces generalmente se olvida, sin embargo, ¡un error en la aplicación será claramente recordado! a ellos. Si puede manejar bien los casos extremos (o situaciones difíciles), puede ofrecer recompensas satisfactorias a los usuarios que regresan a su sitio.
Figura 5. Manejo de errores comunes
El usuario no tiene forma de saber si el problema es un problema de autenticación, un script no encontrado (como es el caso aquí), un error del usuario o algo más en el código. Agregar un código simple puede hacer que este error sea más específico. Consulte el Listado 8, que es responsable de manejar la situación en la que no se encuentra el script o se produce el error de autenticación, y se darán mensajes específicos cuando se produzcan estos errores.
Listado 8. Comprobar códigos de estado válidos
function updatePage() {
si (solicitud.readyState == 4) {
si (solicitud.estado == 200) {
var respuesta = request.responseText.split("|");
document.getElementById("pedido").valor = respuesta[0];
document.getElementById("dirección").innerHTML =
respuesta[1].replace(/n/g, "<br />");
} más si (solicitud.status == 404) {
alerta ("No se encuentra la URL solicitada.");
} más si (solicitud.status == 403) {
alerta("Acceso denegado.");
} demás
alert("el estado es " + request.status);
}
}
Si bien esto sigue siendo bastante simple, proporciona un poco más de información útil. La Figura 6 muestra el mismo error que la Figura 5, pero esta vez el código de manejo de errores explica mejor al usuario o programador qué sucedió exactamente.
Figura 6. Manejo de errores especiales
En nuestra propia aplicación, podríamos considerar borrar el nombre de usuario y la contraseña y agregar un mensaje de error a la pantalla en caso de que se produzca un error de autenticación. Podemos usar un enfoque similar para manejar mejor el script no encontrado u otros errores de tipo 400 (por ejemplo, 405 significa que no se permite un método de solicitud inaceptable, como enviar una solicitud HEAD, y 407 significa que se requiere autenticación de proxy). Sin embargo, no importa qué opción elija, debe comenzar a procesar el código de estado devuelto por el servidor.
Otros tipos de solicitudes
Si realmente desea tener control sobre el objeto XMLHttpRequest, considere implementar esta funcionalidad final agregando la solicitud HEAD a la directiva. En los dos artículos anteriores, presentamos cómo generar solicitudes GET; en un próximo artículo, aprenderá sobre el uso de solicitudes POST para enviar datos al servidor. Sin embargo, con el objetivo de mejorar el manejo de errores y la recopilación de información, debe aprender a generar solicitudes HEAD.
Realizar la solicitud
Realizar la solicitud HEAD es en realidad muy simple; se llama al método open() con "HEAD" (en lugar de "GET" o "POST") como primer parámetro, como se muestra en el Listado 9.
Listado 9. Usando Ajax para generar una
función de solicitud HEAD getSalesData() {
crearSolicitud();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, verdadero);
request.onreadystatechange = actualizarPágina;
solicitud.enviar (nulo);
}
Cuando genera una solicitud HEAD como esta, el servidor no devuelve una respuesta real como lo haría para una solicitud GET o POST. En cambio, el servidor solo devuelve el encabezado del recurso, que incluye cuándo se modificó por última vez el contenido de la respuesta, si el recurso solicitado existe y mucha otra información útil. Puede utilizar esta información para conocer el recurso antes de que el servidor lo procese y lo devuelva.
Lo más sencillo que puede hacer para este tipo de solicitud es simplemente generar el contenido de todos los encabezados de respuesta. Esto le da una idea de lo que está disponible a través de la solicitud HEAD. El Listado 10 proporciona una función de devolución de llamada simple que imprime el contenido del encabezado de respuesta obtenido de la solicitud HEAD.
Listado 10. Genere el contenido del encabezado de respuesta obtenido de la
función de solicitud HEAD updatePage() {
si (solicitud.readyState == 4) {
alerta(request.getAllResponseHeaders());
}
}
Consulte la Figura 7, que muestra los encabezados de respuesta devueltos por una aplicación Ajax simple que realiza una solicitud HEAD al servidor.
Puede utilizar estos encabezados individualmente (desde el tipo de servidor hasta el tipo de contenido) para proporcionar información o funcionalidad adicional en su aplicación Ajax.
Comprobación de la URL
Has visto cómo comprobar errores 404 cuando la URL no existe. Si esto resulta ser un problema común (tal vez falta un script o servlet en particular), entonces es posible que desee verificar la URL antes de realizar una solicitud GET o POST completa. Para implementar esta funcionalidad, genere una solicitud HEAD y luego verifique si hay errores 404 en la función de devolución de llamada. El Listado 11 muestra una función de devolución de llamada simple;
Listado 11. Comprobar si existe una URL
function updatePage() {
si (solicitud.readyState == 4) {
si (solicitud.estado == 200) {
alerta("La URL existe");
} más si (solicitud.status == 404) {
alerta("La URL no existe.");
} demás {
alert("El estado es: " + request.status);
}
}
}
Honestamente, el valor de este código no es tan bueno. El servidor debe responder a la solicitud y construir una respuesta para rellenar el encabezado de respuesta Content-Length, de modo que no se ahorre tiempo de procesamiento. Además, esto lleva tanto tiempo como generar la solicitud y usar una solicitud HEAD para ver si la URL existe, ya que genera la solicitud usando GET o POST en lugar de simplemente manejar el código de error como se muestra en el Listado 7. Sin embargo, a veces es útil saber exactamente qué está disponible actualmente; ¡nunca sabes cuándo entrará en acción tu creatividad o cuándo necesitarás una solicitud HEAD!
Solicitudes HEAD útiles
Un área en la que puede encontrar muy útil la solicitud HEAD es ver la longitud del contenido o el tipo de contenido. Esto puede determinar si es necesario devolver una gran cantidad de datos para manejar la solicitud y si el servidor está intentando devolver datos binarios en lugar de HTML, texto o XML (los tres tipos de datos son más fáciles de procesar en JavaScript que datos binarios).
En estos casos, simplemente use el nombre del encabezado apropiado y páselo al método getResponseHeader() del objeto XMLHttpRequest. Entonces, para obtener la longitud de la respuesta, simplemente llame a request.getResponseHeader("Content-Length");. Para obtener el tipo de contenido, utilice request.getResponseHeader("Content-Type");.
En muchas aplicaciones, generar una solicitud HEAD no agrega ninguna funcionalidad e incluso puede hacer que la solicitud sea más lenta (al forzar una solicitud HEAD a obtener datos sobre la respuesta y luego usar una solicitud GET o POST para obtener la respuesta). Sin embargo, en situaciones en las que no está seguro acerca de un script o componente del lado del servidor, el uso de una solicitud HEAD puede obtener algunos datos básicos sin procesar realmente los datos de respuesta o requerir mucho ancho de banda para enviar la respuesta.
Conclusión
Para muchos programadores web y Ajax, el material presentado en este artículo puede parecer demasiado avanzado. ¿Cuál es el valor de generar una solicitud HEAD? ¿Cuándo necesitas manejar explícitamente los códigos de estado de redireccionamiento en JavaScript? Éstas son buenas preguntas; para aplicaciones simples, la respuesta es que el valor de estas técnicas avanzadas no es muy grande.
Sin embargo, la web ya no es un lugar donde solo es necesario implementar aplicaciones simples, los usuarios se han vuelto más avanzados, los clientes esperan una mejor estabilidad, informes de errores más avanzados y, si una aplicación falla el 1% del tiempo, entonces el administrador podría hacerlo; ser despedido por ello.
Por lo tanto, su trabajo no puede limitarse a aplicaciones simples, sino que requiere una comprensión más profunda de XMLHttpRequest.
·Si puede pensar en varios estados de preparación y comprender cómo estos estados de preparación difieren entre los navegadores, puede depurar rápidamente su aplicación. Incluso puede desarrollar algunas funciones creativas basadas en el estado de preparación e informar el estado solicitado a los usuarios y clientes.
·Si desea controlar los códigos de estado, puede configurar su aplicación para manejar errores de script, respuestas inesperadas y casos extremos. El resultado es una aplicación que funciona correctamente todo el tiempo, no sólo cuando todo está bien.
·Agregue la capacidad de generar solicitudes HEAD, verificar si existe una URL y confirmar si un archivo ha sido modificado, para garantizar que los usuarios puedan obtener páginas válidas y que la información que ven sea la más reciente (lo más importante) para sorprenderlos. lo robusta y versátil que es esta aplicación.
El propósito de este artículo no es hacer que su aplicación se vea elegante, sino ayudarlo a eliminar el foco amarillo y resaltar la belleza del texto, o que se parezca más a un escritorio. Aunque todas estas son características de Ajax (que se tratarán en los próximos artículos), son como una capa de crema sobre el pastel. Si puede utilizar Ajax para construir una base sólida para que su aplicación pueda manejar bien errores y problemas, los usuarios volverán a su sitio y aplicación. En el próximo artículo añadiremos esta técnica intuitiva que hará temblar de emoción a tus clientes. (¡En serio, no querrás perderte el próximo artículo!)