-[ 0x10 ]-------------------------------------------------------------------- -[ HTTP 1.1 ]---------------------------------------------------------------- -[ by Trypsode ]------------------------------------------------------SET-13- [ NOTA DEL EDITOR: SET no se hace responsable de los dolores de cabeza que pueda producir la lectura del presente articulo. Se incluye por la valia de cierta informacion que incluye. Pero ende luego... Trypsode, que la gente puede llegar a dormise ;) No te lo tomes a mal, pero tron, muy... formal. Parece sacado de un trabajo sobre protocolos ] PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO (HTTP 1.1) por : Trypsode 1. Generalidades. El Protocolo de Transferencia de Hipertexto es un protocolo de nivel de aplicacion usado en diferentes tareas, tales como servidores de nombres o sistemas distribuidos de manejo de objetos. Desde 1990 se ha utilizado en la transferencia de datos en la World-Wide Web. En su primera version (HTTP 0.9), el HTTP era un protocolo muy simple con la unica finalidad de transmitir datos de forma secuencial a traves de Internet. En la siguiente version, HTTP 1.0, se mejoro el protocolo haciendo que este soportara mensajes en formato MIME, lo que aumento su versatilidad. Sin embargo, esta version no tenia aun en cuenta detalles como la necesidad de conexiones persistentes, hosts virtuales o los conocidos como multi-homed hosts, host con varias direcciones IP. Estos problemas, unidos a la aparicion de implementaciones inconsistentes del protocolo propiciaron la aparicion de una nueva version, HTTP 1.1, que permitiria a cada una de las aplicaciones implicadas en una comunicacion conocer las capacidades de las demas. El HTTP 1.1 proporciona a las aplicaciones un conjunto abierto de metodos que indican el proposito de la peticion. El metodo mas el Identificador Uniforme de Recurso (URI) son los componentes basicos de las peticiones HTTP, los cuales son transmitidos, junto a las respuestas, de forma similar al correo de Internet, mediante mensajes MIME. Gracias a esto, HTTP proporciona acceso a recursos disponibles a multiples aplicaciones (FTP, GOPHER, WAIS, NNTP y SMTP). El comportamiento basico del HTTP es muy simple: el cliente o Agente de Usuario (UA) envia una peticion al servidor. Esta peticion contiene el metodo, el URI y la version del protocolo, seguido de un mensaje en formato MIME conteniendo los modificadores o cabeceras (headers) de la peticion, la informacion del cliente y un posible campo de datos de usuario. A continuacion el servidor envia una respuesta con un codigo de estado, la version del protocolo, un codigo de exito o error, seguidos de un mensaje MIME que contendra informacion del servidor y, opcionalmente, un campo de datos. La comunicacion entre el agente de usuario y el servidor puede hacerse de varias maneras. La mas simple de ellas es la que consiste en una unica conexion entre el agente de usuario y el servidor. Otro de los casos posibles que se dan al establecer una comunicacion es cuando la peticion y la respuesta pasan por algun intermediario (proxies, gateway o tunnel). Un proxy es un agente que recibe peticiones, las reescribe y las envia al servidor destino. Un gateway es un agente de recepcion, que oculta el protocolo propio del servidor, adaptandolo al HTTP. Un tunnel es un simple retransmisor que recibe mensajes (peticiones o respuestas), y se limita a retransmitirlos. Un agente intermediario (que no sea de tipo tunnel) puede disponer de un cache interno. Esto supone que si este agente tiene en el cache una respuesta que se puede aplicar a una peticion, la envia al UA sin reenviar la peticion al servidor, con lo que se consigue disminuir el trafico en la red. Este tipo de configuracion implica muchas complicaciones en el desarrollo y la administracion de un proxy o gateway. Una comunicacion HTTP se realiza sobre una conexion TCP/IP (aunque se pueden usar otros protocolos de transporte), utilizando normalmente el puerto 80. HTTP 1.0 abre una conexion de transporte por cada peticion o respuesta, en cambio la version 1.1 utiliza el concepto de conexion persistente, por el cual varias peticiones y respuestas pueden cursarse por una misma conexion de transporte. En la mayoria de las ocasiones un recurso (p. ej.: una pagina HTML) tiene asociados otros multiples recursos (imagenes, scripts, frames, ...). Esto hace que el cliente haga varias peticiones en un periodo corto de tiempo. Si se trata de un cliente HTTP 1.0 por cada peticion se abrira una conexion TCP, con lo que se sobrecarga innecesariamente la red. En cambio, un cliente HTTP 1.1 realizara todas las peticiones sobre una misma conexion de transporte, lo que tiene varias ventajas: -Se ahorra tiempo de CPU y memoria al abrir menos conexiones TCP. -Se pueden simultanear varias peticiones en una misma conexion, aprovechando esta mucho mas en menos tiempo. Esto se conoce como Pipelining. -Se reduce el trafico de la red al reducir el numero de paquetes TCP de conexion, liberacion y de control. -Se permite la notificacion de errores sin cortar la conexion, lo que agiliza la recuperacion. -Se posibilita el control de flujo. 1.1 Compatibilidad con otras versiones. Debido a que se supone que, durante un tiempo, coexistiran en el mercado diferentes versiones del protocolo, el HTTP 1.1 se ha dise€ado para facilitar el soporte para el resto de versiones (1.0 y 0.9). Por ello se recomienda que las implementaciones comerciales incluyan unas caracteristicas especificas en lo referente a compatibilidad. En concreto un servidor HTTP 1.1 deberia: -reconocer el formato de la Request-Line de las peticiones HTTP 0.9, 1.0 y 1.1. -entender una peticion valida en formato HTTP 0.9, 1.0 y 1.1. -responder apropiadamente con un mensaje en la mayor version que soporte el cliente. Un cliente HTTP 1.1 deberia: -reconocer el formato de la Status-Line de las respuestas HTTP 1.0 y 1.1. -entender cualquier respuesta valida el formato HTTP 0.9, 1.0 y 1.1. 2. Notacion. La especificacion del protocolo HTTP utiliza la notacion "argumented Backus-Naur Form" (BNF) tal como se hace en la RFC 822: - Nombre de las reglas. El nombre de una regla es el propio nombre sin ningun tipo de parentesis o corchetes, separado de la definicion mediante un signo de "igual que" ("="). HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT - Alternativas. Son los elementos separados por una barra (" / " o " | "). transfer-coding = "chunked" | transfer-extension - Alternativas locales. Los elementos encerrados entre parentesis se consideran como un unico elemento. Rule = (elem (foo | bar) elem) - Repeticion. Un asterisco (" * ") delante de cualquier elemento indica repeticion. *element Donde indica "al menos" y "como maximo". Los valores por defecto son 0 (al menos) e infinito (como maximo) : *element. primary-tag = 1*8ALPHA - Opcional. Un elemento encerrado entre corchetes quiere decir "campo opcional". entity-tag = [ weak ] opaque-tag - Repeticion especifica. Un numero que precede a un elemento indica un numero exacto de repeticiones obligatorio. Num = 2DIGIT - Listas. Es similar a la repeticion pero con " # " en vez de " * ". #element , indica al menos y como maximo elementos separados por comas. Rule = 1#2element - Comentarios. Se indican con un punto y coma a la derecha del resto de la definicion de la regla, el comentario se extiende hasta el final de la linea. Sun, 06 Nov 1994 08:49:37 GMT ;RFC 822,updated by RFC 1123 Reglas Basicas ; ( Octal, Decimal.) OCTET = ; ( 0-177, 0 -127. ) CHAR = ; ( 0-177, 0.-127.) ALPHA = ; (101-132, 65.- 90.) ; (141-172, 97.-122.) UPALPHA = LOALPHA = DIGIT = ; ( 60- 71, 48.- 57.) CTL = ; ( 177, 127.) CR = ; ( 15, 13.) LF = ; ( 12, 10.) SP = ; ( 40, 32.) HT = ; ( 11, 9.) <"> = ; ( 42, 34.) CRLF = CR LF LWS = [ CRLF ] 1*( SP | HT ) ; semantics = SPACE HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT token = 1* linear-white-space = 1*([CRLF] LWS) ; semantics = SPACE ; CRLF => folding specials = "(" | ")" | "<" | ">" | "@" ; Must be in quoted- | "," | ";" | ":" | "\" | <"> ; string, to use | "." | "[" | "]" ; within a word. separators = specials | linear-white-space | comment TEXT = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. quoted-string = <"> *(qtext | quoted-pair) <">; Regular qtext or ; quoted chars. qtext = , ; => may be folded "\" & CR, and including linear-white-space> domain-literal = "[" *(dtext | quoted-pair) "]" dtext = may be folded "]", "\" & CR, & including linear-white-space> comment = "(" *(ctext | quoted-pair | comment) ")" ctext = may be folded ")", "\" & CR, & including linear-white-space> quoted-pair = "\" CHAR ; may quote any char phrase = 1*word ; Sequence of words word = atom | quoted-string 3. Parametros. 3.1 Version HTTP. La version del protocolo HTTP se envia para indicar el formato del mensaje y las capacidades tanto del origen como del destino. En HTTP la version se define de la siguiente forma: HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT donde cada uno de los digitos es independiente del otro. Esto significa que, por ejemplo, la version 2.5 sera menor o mas antigua que la 2.13 (5 < 13). Si en la version, hay un cero, por ejemplo 3.02, este no sera enviado, por lo que 3.02 es igual que 3.2. La version que una aplicacion debera enviar sera la mas alta de todas aquellas con las que sea compatible. Nuevamente, aparece aqui la problematica de los proxies y gateways. Cuando una aplicacion intermediaria recibe mensajes en una version distinta a la de los que envia, esta tiene que adaptar dicho mensaje de una version a otra, siempre que esto sea posible. Aun asi, logicamente, un proxy o gateway no podra enviar un mensaje con una version superior a la que el pueda manejar. Si se diera este caso, la aplicacion deberia responder con un error o conmutar a modo tunnel. 3.2 Identificadores Uniformes de Recurso (URI's). Los URI's, tambien conocidos como Universal Resource Identifiers, Uniform Resource Locators (URL) o Uniform Resource Name (URN), pueden ser representados en dos formas: la forma absoluta y la forma relativa. En la forma absoluta se expresa toda la informacion de localizacion del recurso: host, directorios, nombre de fichero ... En cambio en la forma relativa se tiene en cuenta el contexto en el que esta funcionando la aplicacion. El URI se define de la siguiente forma: URI = ( absoluteURI | relativeURI ) [ "#" fragment ] absoluteURI = scheme ":" *( uchar | reserved ) relativeURI = net_path | abs_path | rel_path net_path = "//" net_loc [ abs_path ] abs_path = "/" rel_path rel_path = [ path ] [ ";" params ] [ "?" query ] path = fsegment *( "/" segment ) fsegment = 1*pchar segment = *pchar params = param *( ";" param ) param = *( pchar | "/" ) scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) net_loc = *( pchar | ";" | "?" ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | ":" | "@" | "&" | "=" | "+" uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" extra = "!" | "*" | "'" | "(" | ")" | "," safe = "$" | "-" | "_" | "." unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" national = En la RFC 1738 se define esta sintaxis por completo, aunque en HTTP no se limita el uso del conjunto de caracteres ASCII, pudiendose utilizar cualquiera de ellos. Asimismo, la especificacion del protocolo no establece un limite en la longitud de los URI's, lo que podria causar errores en algunas implementaciones antiguas; por esto se debe intentar limitarlos a 255 caracteres. Este es el formato general de URI en Internet. Para el caso en concreto de HTTP el URI se define: http_URL = "http:" "//" host [ ":" port ] [ abs_path ] host = port = *DIGIT ; optional, 80 default 3.3 Codigos de contenido y transferencia. Los codigos de contenido indican las transformaciones que se han aplicado a los datos a transferir. Ejemplos de transformaciones pueden ser compresion, codificacion en ASCII estandar. Al cliente le interesa conocer esta informacion para que la transmision se realice en forma codificada y sea este quien lleve a cabo la conversion al formato original. La definicion de este campo es: content-coding = token El organismo encargado de registrar todos los identificadores de codigo de contenido es el Internet Assigned Numbers Authority (IANA). HTTP utiliza los conocidos como Internet Media Types, que permiten elegir y negociar el tipo de los datos. media-type = type "/" subtype *( ";" parameter ) type = token subtype = token Parameters may follow the type/subtype in the form of attribute/value pairs. parameter = attribute "=" value attribute = token value = token | quoted-string Si la aplicacion reconoce el tipo, deberia abrir el recurso por si misma o utilizando una aplicacion externa. En el caso de que no la reconozca debe informar al usuario. 4. Definicion del mensaje HTTP. HTTP-message = Request | Response ; HTTP/1.1 messages Los mensajes HTTP siguen el formato generico que aparece en la RFC 822. Este comienza con una start-line, seguida de uno o mas campos llamados headers, un retorno de carro (CRLF) y opcionalmente el cuerpo del mensaje: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line Los campos de cabecera (header fields), siguen el mismo formato dado por la RFC 822: message-header = field-name ":" [ field-value ] CRLF field-name = token field-value = *( field-content | LWS ) field-content = El orden de estos campos no esta establecido, aunque en la practica es mas correcto enviar los campos generales primero, despues los campos especificos de la peticion o la respuesta y, por ultimo, los campos propios de la informacion a transmitir. Por tanto, aunque no este definido, el orden si es relevante para interpretar el mensaje y por ello ningun proxy puede cambiar este orden. La existencia del cuerpo en la peticion se indica por la aparicion de las cabeceras Content-Length y Transfer-Encoding. En la respuesta, esto depende del metodo especificado en la peticion en conjuncion con el codigo de estado. Cuando un mensaje incluye cuerpo, la longitud de este se determinara por uno de las siguientes consideraciones: - si una respuesta no debe llevar cuerpo, el mensaje acaba con una linea en blanco. - si la cabecera Transfer-Encoding indica que se ha aplicado chunked transfer coding, la longitud sera la definida en esta cabecera. - si aparece la cabecera Content-Length, esa es la longitud del cuerpo. - al cerrarse la conexion, el servidor envia la cabecera Content-Length. Si una peticion tiene cuerpo y no incluye cabecera de longitud, el servidor respondera con un mensaje de peticion erronea o de longitud requerida. Igualmente si se detecta que la longitud es erronea se notificara al usuario y al cliente con un error. Algunos campos se pueden aplicar tanto a peticiones como a respuestas, aunque no al cuerpo del mensaje. Estos campos solo podran ser actualizados en una nueva revision del protocolo. general-header = Cache-Control | Connection | Date | Pragma | Transfer-Encoding | Upgrade | Via 5. Mensaje de peticion. El mensaje de peticion desde el cliente al servidor tiene la siguiente estructura: Request = Request-Line *( general-header | request-header | entity-header ) CRLF [ message-body ] La peticion comienza con el campo Request-Line, que se compone del metodo el identificador del recurso y la version del protocolo, sin ningun retorno de carro excepto el del final del campo: Request-Line = Method SP Request-URI SP HTTP-Version CRLF El campo Method indica la accion a aplicar sobre el recurso apuntado por el URI. Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | extension-method extension-method = token El servidor indicara en la respuesta si el metodo solicitado se puede aplicar, mediante un codigo de estado diferente segun la situacion (resultado satisfactorio, no permitido, no implementado ...). El URI identifica el recurso sobre el que se aplicara el metodo: Request-URI = "*" | absoluteURI | abs_path Si en el campo URI aparece el caracter "*", el metodo no se aplicara a ningun recurso en particular sino al propio servidor. Los campos de cabecera de la peticion (Request Headers Fields) son utilizados por el cliente para dar al servidor informacion adicional sobre la peticion o el propio cliente: request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Modified-Since | If-Match | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | User-Agent 5.1 Definicion de metodos. - OPTIONS. El metodo OPTIONS indica que la peticion es de solicitud de informacion de las opciones y requerimientos de un recurso o del propio servidor. - GET. Este metodo indica al servidor que envie la informacion indicada por el URI. El significado del metodo GET puede verse modificado por las cabeceras: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, o If-Range; indicando un GET condicionado a la situacion indicada por alguna de estas cabeceras, en el caso de If-Range se trata de un GET parcial, similar al RESTART del protocolo FTP. Estas opciones se usan para no sobrecargar la red y utilizar satisfactoriamente el cache. - HEAD. El metodo HEAD indica la misma accion que GET excepto que la respuesta solo incluira la informacion de las cabeceras y no el cuerpo. Este metodo permite al cliente obtener la informacion de un recurso sin que el servidor lo envie, lo que se usa normalmente para validar enlaces de hipertexto, modificaciones, etc. - POST. El metodo POST se usa para solicitar al servidor la asociacion del cuerpo de datos de la peticion al recurso indicado por el URI. POST se usa, entre otros, para: enviar mensajes de correo electronico. enviar el resultado de un formulario. agregar elementos a un base de datos. - PUT. El metodo PUT indica al servidor que se desea guardar bajo el URI indicado la informacion incluida en el cuerpo del mensaje. La diferencia entre POST y PUT se basa en que mediante una peticion POST se envia informacion a un recurso para que este la procese, mientras que en una peticion PUT se solicita la creacion o actualizacion de un recurso con el URI indicado. - DELETE. El metodo DELETE pide al servidor que elimine el recurso indicado. - TRACE. El metodo TRACE se usa para solicitar al servidor toda la informacion que le envie el cliente. De esta manera el cliente conoce lo que llega al otro lado de la conexion y utilizarla para hacer pruebas o diagnosticos. 6. Mensaje de respuesta. Tras recibir e interpretar la peticion, el servidor envia un mensaje de respuesta: Response = Status-Line *( general-header | response-header | entity-header ) CRLF [ message-body ] Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Reason-Phrase = * El codigo de estado es un entero de 3 cifras que identifica el resultado de procesar una peticion. El campo Reason-Phrase consiste en una explicacion textual del codigo de estado, destinado a un usuario humano. La primera cifra del codigo de estado define la clase de la respuesta: 1: Informacion -> Se ha recibido la peticion. 2: Resultado satisfactorio. 3: Redireccion -> Se han de realizar mas acciones para completar la peticion. 4: Error del cliente -> Error de sintaxis en la peticion. 5: Error del servidor -> El servidor no puede completar una peticion que parece ser valida. Los campos de cabecera de la respuesta permiten al servidor enviar informacion adicional sobre la respuesta. response-header = Accept-Ranges | Age | Location | Proxy-Authenticate | Public | Retry-After | Server | Set-Proxy | Vary | Warning | WWW-Authenticate 6.1 Codigos de estado. Los codigos de estado informan al cliente sobre el resultado de la accion indicada en la peticion. Segun la primera cifra se clasifican en cinco clases. Informativos 1xx Indican respuestas provisionales o de confirmacion de que se ha recibido la peticion y se esta procesando. Esta clase no existe en la version 1.0 de HTTP. -100 Continue. Indica al cliente que puede continuar enviando la peticion. -101 Switching Protocols. El servidor esta cambiando el protocolo de aplicacion, por ejemplo de HTTP/1.0 a HTTP/1.1. Exito 2xx Indican que la peticion ha sido recibida, procesada y aceptada. -200 OK. La peticion se ha completado con exito. En la respuesta se envia la informacion solicitada. -201 Created. Se ha cumplido la solicitud de creacion de un nuevo recurso. -202 Accepted. La peticion se ha aceptado, pero aun no se ha completado el proceso. -203 Non-Authoritative Information. La informacion enviada no es la original, sino una copia local o de otro servidor. -204 No Content. El servidor ha completado la peticion pero no tiene informacion nueva que enviar. -205 Reset Content. El servidor ha cumplido la peticion y el agente de usuario debe volver a cargar el documento origen de la peticion. -206 Partial Content. El servidor ha completado una peticion GET parcial. Redireccion 3xx Esta clase indica que el agente de usuario ha de realizar mas acciones para poder cumplir la peticion. Estas acciones se llevaran a cabo sin la intervencion del usuario solo si el metodo especificado es GET o HEAD. El usuario no debera redirigir una peticion mas de cinco veces, porque se podria entrar en un bucle cerrado. -300 Multiple Choices. Se utiliza cuando un recurso tiene mas de una presentacion posible y el agente de usuario ha de elegir una de ellas. -301 Moved Permanently. El recurso ha sido asignado a un nuevo URI definitivamente, incluido en la respuesta. -302 Moved Temporarily. El recurso se ha movido temporalmente a un nuevo URI. -303 See Other. La respuesta a la peticion se puede encontrar bajo un URI diferente, y deberia ser obtenida mediante una peticion GET de ese URI. -304 Not Modified. Si el metodo de la peticion ha sido GET condicional, mediante este codigo se informa al cliente que el documento no ha sido cambiado desde la ultima vez que se accedio a el. -305 Use Proxy. El servidor origen indica al cliente con este codigo que para acceder al recurso ha de utilizar un proxy. -306 Switch Proxy. Este codigo lo genera un servidor proxy para indicar al cliente que deberia utilizar la cabecera Set-Proxy y utilizar el proxy indicado, aunque no es obligatorio. Error del cliente 4xx Esta clase se utiliza para indicar que el cliente posiblemente ha cometido un error. -400 Bad Request. La sintaxis de la peticion es erronea. -401 Unauthorized. La peticion debe incluir autenticacion. El cliente debe repetir la peticion con la cabecera Authorization. -402 Payment Required. Codigo reservado para uso futuro. -403 Forbidden. El servidor entiende la peticion, pero se niega a cumplirla. -404 Not Found. El servidor no ha encontrado ningun recurso identificado con el URI indicado. -405 Method Not Allowed. No se puede aplicar al recurso identificado por el URI el metodo especificado en la peticion. -406 Not Acceptable. El recurso no se puede transmitir aceptando las cabeceras incluidas en la peticion. -407 Proxy Authentication Required. Este codigo es similar al 401 Unathorized, pero la autenticacion la debe realizar el proxy. -408 Request Timeout. El cliente no ha enviado ninguna peticion durante el tiempo que el servidor ha estado esperandola. -409 Conflict. La peticion no se ha podido completar debido al estado actual del recurso. -410 Gone. El recurso solicitado no esta disponible ni lo estara mas en ese URI. -411 Length Required. La peticion requiere que el campo Content-Length este definido. -412 Precondition Failed. No se han cumplido las condiciones establecidas por las cabeceras de la peticion. -413 Request Entity Too Large. El recurso solicitado es demasiado grande para que el servidor lo pueda manejar. -414 Request-URI Too Long. El URI indicado es mas largo de lo que el servidor puede interpretar. -415 Unsupported Media Type. El servidor no puede completar la peticion debido a que esta se ha enviado en un formato no soportado por el recurso indicado. -416 Requested range not valid. Indica que se ha recibido una peticion GET parcial y el valor de la cabecera Range excede los limites del recurso especificado. -417 Expectation Failed. El comportamiento solicitado por el cliente en la cabecera Expect no ha podido ser cumplido por el servidor. -418 Reauthentication Required. Es similar al codigo 401 Unathorized, pero en este caso el agente de usuario debe volver a pedir los datos de usuario a este y reenviar la peticion. -419 Proxy Reauthentication Required. Es similar a 407 Proxy Authentication Required, pero el agente tiene que solicitar los datos al usuario antes de que la peticion se reenvie. Error del servidor 5xx Indican que el servidor ha causado un error o es incapaz de realizar con exito la peticion. -500 Internal Server Error. El servidor ha encontrado un error inesperado que le ha impedido completar la peticion. -501 Not Implemented. El servidor no soporta la funcionalidad requerida por la peticion. -502 Bad Gateway. Un servidor proxy o gateway ha recibido una respuesta no valida del servidor origen. -503 Service Unavailable. El servidor no puede atender temporalmente la peticion por sobrecarga o mantenimiento del mismo. Si se conoce, se enviara el tiempo que pasara hasta que el servicio este disponible de nuevo. -504 Gateway Timeout. Un servidor proxy o gateway no ha recibido ninguna respuesta del servidor origen durante el tiempo que la ha estado esperando. -505 HTTP Version Not Supported. El servidor no soporta la version del protocolo indicada en la peticion. -506 Partial Update Not Implemented. El servidor no soporta GET parcial sobre ese recurso. 7. Caches HTTP. El protocolo HTTP facilita en gran medida el uso de caches de respuestas, con el fin de mejorar el funcionamiento. Estos caches serian una complicacion inutil si no supusieran una mejora sustancial, la cual se consigue, pues se elimina la necesidad de enviar peticiones en muchos casos y enviar respuestas completas en otros lo que libera gran parte del trafico de la red, reduciendo el ancho de banda requerido para una comunicacion. El protocolo permite negociar el grado de transparencia del cache, el cual dependera en gran medida de la aplicacion. El HTTP incorpora los siguientes elementos: -caracteristicas que proporcionan una total transparencia cuando todas los elementos involucrados lo solicitan. -caracteristicas que permiten al cliente y al servidor solicitar y negociar un funcionamiento no transparente. -caracteristicas que permiten incluir advertencias en las respuestas cuando no es posible conservar la transparencia. Un cache HTTP conservara siempre cualquier respuesta satisfactoria y puede enviarsela sin validacion al cliente si es reciente o tras una validacion del servidor si no lo es. Concretamente cualquier respuesta con los codigos de estado 200, 203, 206, 300, 301 o 410 (ver punto 6.1) puede ser conservada a menos que se prohiba explicitamente en la respuesta (Cache-Control: no-store). El cliente normalmente podra detectar cuando una respuesta proviene de un cache tan solo comparando la cabecera de fecha con la hora real del sistema. Por motivos de seguridad y privacidad, se hace una distincion entre caches compartidos y no compartidos. Un cache no compartido solo es accesible por un unico usuario, el resto se consideran compartidos. Un cache compartido no podra conservar ninguna respuesta que incluya la cabecera de autorizacion. 8. HTTP-NG y SCP. Hasta este momento la ultima version del protocolo HTTP que esta presente en el mercado es la HTTP/1.1. Sin embargo, desde hace algun tiempo se encuentra en fase de desarrollo una nueva version conocida como Next Generation Hypertext Transport Protocol o HTTP-NG. En la definicion de este protocolo se han utilizado algunas recomendaciones del estandar OSI. Asi pues, se ha olvidado la notacion "argumented Backus-Naur Form" (BNF), siendo reemplazada por ASN.1 junto a las reglas de codificacion PER (Packed encoding rules), lo que permite reducir el ancho de banda requerido. Tambien se ha optado por montar un protocolo de sesion entre el protocolo de transporte (TCP) y el propio HTTP, este ha sido denominado Session Control Protocol (SCP). El SCP tiene un dise€o muy simple, ofrece un servicio no confirmado sin negociacion (solo se rechazan los mensajes erroneos). Permite a un cliente y a un servidor mantener varias comunicaciones a traves de una unica conexion de transporte. 8.1 Comportamiento. El orden en el que se intercambian los mensajes (nivel de sincronismo) se negocia durante la conexion: -si el nivel es sincrono, el servidor debe completar cada operacion antes de comenzar una nueva, y ha de hacerlo en el orden que has sido solicitadas. -si el nivel es fuera de orden, el servidor ha de completar igualmente una operacion antes de comenzar la siguiente, pero no es necesario que se respete el orden de recepcion. -si el nivel es interleaved, se pueden realizar varias operaciones a la vez y en cualquier orden. -si el nivel es predictivo, ademas de enviar varias respuestas a la vez, el servidor puede enviar respuestas antes de recibir las peticiones correspondientes. Durante el intercambio de mensajes el cliente puede enviar una peticion de inicializacion para cambiar los parametros de la comunicacion, por ejemplo el nivel de sincronismo. Antes de llevar a cabo la reinicializacion, el servidor ha de completar todas las operaciones que queden pendientes. Aun quedan muchos aspectos sin completar en la especificacion del HTTP-NG, por lo que cualquier dato puede ser modificado en sucesivas revisiones. Para una informacion actualizada, se recomienda visitar el sitio web oficial del W3-Consortium: http://www.w3.org/hypertext/WWW/Protocols/HTTP-NG/. Trypsode: gmag@lettera.skios.es