UNIVERSIDAD NACIONAL MICAELA BASTIDAS DE APURMAC

Escuela Acadmico Pr ofesional de Ingeniera Informtica y Sistemas

TEMA: CODIGOS DE ESTADO

Docente: Jorge Serrano Quispe Presentado por: Evelin Angelino Chancco

11/05/2011

INTRODUCCION

Cuando un servidor Web responde a una peticin de un navegador u otro cliente Web, la respuesta consiste tpicamente en una lnea de estado, algunas cabeceras de respuesta, una lnea en blanco, y el documento. Aqu tenemos un ejemplo mnimo: HTTP/1.1 200 OK Content-Type: text/plain Hello World La lnea de estado consiste en la versin HTTP, y un entero que se interpreta como cdigo de estado, y un mensaje muy corto que corresponde con el cdigo de estado. En la mayora de los casos, todas las cabeceras son opcionales excepto Content-Type, que especifica el tipo MIME del documento que sigue. Aunque muchas respuestas contienen un documento, algunas no lo tienen. Por ejemplo, las respuestas a peticiones HEAD nunca deberan incluir un documento, y hay una gran variedad de cdigos de estado qu e esencialmente indican fallos, y o no incluyen un documento o slo incluyen un pequeo "mensaje de error de documento". Los servlets pueden realizar una variedad de tareas manipulando la lnea de estado y las cabeceras de respuesta. Por ejemplo, reenviar al usuario a otros sites; indicar que el documento adjunto es una imagen, un fichero HTML; decirle al usuario que se requiere una password para acceder al documento

INDICE

1. Comunicacin entre el navegador y el servidor.04 2. Cdigos de estado 05 2.1. Respuestas Informativas: 1XX. 05 2.2. Peticiones Correctas; 2XX 05 2.3. Redirecciones: 3XX.. 06 2.4. Errores del Cliente: 4XX. 06 2.5. Errores del Servidor: 5XX 08 3. Anexo09

I.

COMUNICACIN ENTRE EL NAVEGADOR Y EL SERVIDOR

La comunicacin entre el navegador y el servidor se lleva a cabo en dos etapas:

y y

El navegador realiza una solicitud HTTP El servidor procesa la solicitud y despus enva una respuesta HTTP

En realidad, la comunicacin se realiza en ms etapas si se considera el procesamiento de l a solicitud en el servidor. Dado que slo nos ocupamos del protocolo HTTP.

Solicitud HTTP
Una solicitud HTTP es un conjunto de lneas que el navegador enva al servidor. Incluye:
y

Una lnea de solicitud : es una lnea que especifica el tipo de documento solicitado, el mtodo que se aplicar y la versin del protocolo utilizada. La lnea est formada por tres elementos que deben estar separados por un espacio: o el mtodo o la direccin URL o la versin del protocolo utilizada por el cliente (por lo general, HTTP/1.0) Los campos del encabezado de solicitud: es un conjunto de lneas opcionales que permiten aportar informacin adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas lneas est formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado. El cuerpo de la solicitud : es un conjunto de lneas opcionales que deben estar separadas de las lneas precedentes por una lnea en blanco y, por ejemplo, permiten que se enven datos por un comando POST durante la transmisin de datos al servidor utilizando un formulario.
Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de lnea):

II.

CODIGOS DE ESTADO

La siguiente es una lista de cdigos de respuesta del HTTP y frases estndar asociadas, destinadas a dar una descripcin corta del estatus. Son los cdigos que se ven cuando el navegador no puede mostrar la pgina solicitada. El cdigo de respuesta est formado por tres dgitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error.

1. 1XX: RESPUESTAS INFORMATIVAS

Esta clase de cdigo de estatus indica una respuesta provisional, que consiste nicamente en la lnea de estatus y en encabezados opcionales, y es terminada por una lnea vaca. Desde que HTTP/1.0 no defina cdigos de estatus 1xx, los servidores no deben enviar una respuesta 1xx a un cliente HTTP/1.0, excepto en condiciones experimentales.

Cdigo: 1xx 100 101

102

Mensaje Continue Switching Protocols

process

Descripcin Contina con peticin parcial. El servidor cumplir con la cabecera Upgrade y cambiar a un protocolo diferente. Procesando (WebDAV - RFC 2518)

2. 2XX: PETICIONES CORRECTAS

Esta clase de cdigo de estado indica que la peticin fue recibida correctamente, entendida y aceptada.

Cdigo: 2xx 200 201

202

Mensaje ok Created
Accepted

203

Non-Authoritative Information No Content

204

205

Reset Content

206 207

Partial Content Estado mltiple (Multi-Status, WebDAV)

Descripcin Respuesta estndar para peticiones correctas. La peticin ha sido completada y ha resultado en la creacin de un nuevo recurso. La peticin ha sido aceptada para procesamiento, pero este no ha sido completado. La peticin eventualmente pudiere no ser satisfecha, ya que podra ser no permitida o prohibida cuando el procesamiento tenga lugar. El documento est siendo devuelto normalmente, pero algunas cabeceras de respuesta podran ser incorrectas porque se est usando una copia del documento. No hay un documento nuevo; el navegador contina mostrando el documento anterior. Esto es til si el usuario recarga peridicamente una pgina y podemos determinar que la pgina anterior ya est actualizada. Sin embargo, esto no funciona para pginas que se recargan automticamente mediante cabeceras de respuesta Refresh o su equivalente <META HTTP-EQUIV="Refresh" ...> ,ya que al devolver este cdigo de estado se pararn futuras recargas. No hay documento nuevo, pero el navegador debera resetear el documento. Usado para forzar al navegador a borrar los contenidos de los campos de un formulario CGI. El cliente enva una peticin parcial con una cabecera Range, y el servidor la ha completado. El cuerpo del mensaje que sigue es un mensaje XML y puede contener algn nmero de cdigos de respuesta separados, dependiendo de cuntas sub-peticiones sean hechas.

3. 3XX: REDIRECCIONES
Esta clase de cdigo de estado indica que una accin subsecuente necesita efectuarse por el agente de usuario para completar la peticin. La accin requerida puede ser llevada a cabo por el agente de usuario sin interaccin con el usuario si y slo si el mtodo utilizado en la segunda peticin es GET o HEAD. El agente de usuario no debe redirigir automticamente una peticin ms de 5 veces, dado que tal funcionamiento indica usualmente un Bucle infinito.

Cdigo: 3xx 300

Mensaje Multiple Choices

301

Moved Permanently Found

302

303

See Other

304

Not Modified

305 306

Use Proxy Cambie de proxy Temporary Redirect

Descripcin El documento pedido se puede encontrar en varios sitios; sern listados en el documento devuelto. Si el servidor tiene una opcin preferida, debera listarse en la cabecera de respuesta Location . El documento pedido est en algn lugar, y la URL se da en la cabecera de respuesta Location. Los navegadores deberan seguir automticamente el enlace a la nueva URL. Similar a 301, excepto que la nueva URL debera ser interpretada como reemplazada temporalmente, no permanentemente. Igual que 301/302, excepto que si la peticin original era POST, el documento redirigido (dado en la cabecera Location) debera ser recuperado mediante GET. El cliente tiene un documento en el cach y realiza una peticin condicional (normalmente suministrando una cabecera IfModified-Since indicando que slo quiere documentos ms nuevos que la fecha especificada). El servidor quiere decirle al cliente que el viejo documento del cach todava est en uso. El documento pedido debera recuperarse mediante el proxy listado en la cabecera Location. Esta respuesta est descontinuada.

307

Es idntica a 302 ("Found" o "Temporarily Moved"). Fue adido a HTTP 1.1 ya que muchos navegadores siguen errneamente la redireccin de una respuesta 302 incluso si el mensaje original fue un POST, y slo se debe seguir la redireccin de una peticin POST en respuestas 303. Esta respuesta es algo ambgua: sigue el redireccionamiento para peticiones GET y POST en el caso de respuestas 303, y en el caso de respuesta 307 slo sigue la redireccin de peticiones GET. Nota: por alguna razn no existe una constante en HttpServletResponse que corresponda con este cdigo de estado.

4. 4XX ERRORES DEL CLIENTE

La intencin de la clase de cdigos de respuesta 4xx es para casos en los cuales el cliente parece haber errado la peticin. Excepto cuando se responde a una peticin HEAD, el servidor debe incluir una entidad que contenga una explicacin a la situacin de error, y si es una condicin temporal o permanente. Estos cdigos de estado son aplicables a cualquier mtodo de solicitud (como GET o POST). Los agentes de usuario deben desplegar cualquier entidad al usuario. Estos son tpicamente los cdigos de respuesta de error ms comnmente encontrados.

Cdigo: 4xx
400

Mensaje
bad request

401

unauthorized

402 403 404

payment required forbidden not found

405 406 407 408 409

Method Not Allowed Not Acceptable Proxy Authentication Required Request Timeout Conflict

410

Gone

411 412 413

Length Required Precondition Failed Request Entity Too Large Request URI Too Long Unsupported Media Type Requested Range Not Satisfiable Expectation Failed Entidad no procesable Bloqueado Fall dependencia Coleccin sin ordenar

414 415 416 417 421 422 423 424 425

Descripcin La sintaxis de la solicitud se encuentra formulada de manera errnea o es imposible de responder. Los parmetros del mensaje aportan las especificaciones de formularios de autorizacin que se admiten. El cliente debe reformular la solicitud con los datos de autorizacin correctos. El cliente debe reformular la solicitud con los datos de pago correctos. El acceso al recurso simplemente se deniega. Un clsico. El servidor no hall nada en la direccin especificada. Se ha abandonado sin dejar una direccin para redireccionar. El mtodo de la peticin (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) no estaba permitido para este recurso particular. El recurso indicado genera un tipo MIME incompatible con el especificado por el cliente mediante su cabecera Accept. Similar a 401, pero el servidor proxy debera devolver una cabecera Proxy-Authenticate. El cliente tarda demasiado en envar la peticin. Usualmente asociado con peticiones PUT; usado para situaciones como la carga de una versin incorrecta de un fichero. El documento se ha ido; no se conoce la direccin de reenvio. Difiere de la 404 en que se sabe que el documento se ha ido permanentemente, no slo est indisponible por alguna razn desconocida como con 404. El servidor no puede procesar la peticin a menos que el cliente enve una cabecera Content-Length. Alguna condicin previa especificada en la peticin era falsa. El documento pedido es mayor que lo que el servidor quiere manejar ahora. Si el servidor cree que puede manejarlo ms tarde, debera incluir una cabecera Retry-After. La URI es demasiado larga.
La peticin est en un formato desconocido. El cliente incluy una cabecera Range no satisfactoria en la peticin. No se puede conseguir el valor de la cabecera Expect. Hay muchas conexiones desde esta direccin de internet La solicitud est bien formada pero fue imposible seguirla debido a errores semnticos. El recurso al que se est teniendo acceso est bloqueado. La solicitud fall debido a una falla en la solicitud previa. Definido en los drafts de WebDav Advanced Collections, pero no est presente en "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol" (RFC 3648). El cliente debera cambiarse a TLS/1.0. Una extensin de Microsoft: La peticin debera ser reintentada despus de hacer la accin apropiada.

426 449

Actualizacin requerida Reintente con

5. 5XX ERRORES DE SERVIDOR

Los cdigos de respuesta que comienzan con el dgito "5" indican casos en los cuales el servidor tiene registrado an antes de servir la solicitud, que est errado o es incapaz de ejecutar la peticin. Excepto cuando est respondiendo a un mtodo HEAD, el servidor debe incluir una entidad que contenga una explicacin de la situacin de error, y si es una condicin temporal o permanente. Los agentes de usuario deben desplegar cualquier entidad incluida al usuario. Estos cdigos de repuesta son aplicables a cualquier mtodo de peticin.

Cdigo: 5xx
500 501 502

Mensaje

503

504 505 506 507 509 510

Descripcin El servidor encontr una condicin inesperada que le internal error impide seguir con la solicitud. not implemented El servidor no admite el servicio solicitado. El servidor que acta como una puerta de enlace o proxy ha bad gateway recibido una respuesta no vlida del servidor al que intenta acceder. El servidor no puede responder en ese momento debido a que se encuentra congestionado (todas las lneas de service unavailable comunicacin se encuentran congestionadas, intntelo de nuevo ms adelante). La respuesta del servidor ha llevado demasiado tiempo en relacin al tiempo de espera que la puerta de enlace poda gateway timeout admitir (excedi el tiempo asignado). http version not El servidor no soporta la versin de HTTP indicada en la supported lnea de peticin. Variante tambin negocia Almacenamiento insuficiente Lmite de ancho de Este cdigo de estatus, mientras que es utilizado por banda excedido muchos servidores, no es oficial. No extendido

III.

ANEXO