TOP
Autores
TOTAL
LecturasSET 13
97894 visitas
- Contenidos - SET Staff
- Editorial - Editor
- Noticias - SET Staff
- Cambios - Paseante & Falken
- Hijacking - ~AtilA~
- Si alguien llama a tu puerta... - Paseante
- Curso basico practico de crackeo de virus - +NetBul
- Proyectos, peticiones, avisos - SET Staff
- GSM - Segunda Parte - Falken
- Los bugs del mes - SET Staff
- Hackear el Teletexto - ArKaNo
- La voz del lector - SET Staff
- Introduccion a Iberpac I - El Nuevo Eljaker
- Diseccion del 8086 - Sir Willy the Psikopath
- Jugando con ensamblador - Tzalik
- Spanish Phreaking Tools - Falken
- HTTP 1.1 - Trypsode
- Despedida - SET Staff
- Fuentes Extract - SET Staff
- Llaves PGP - SET Staff
HTTP 1.1
6202
Autor: Trypsode
-[ 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.
<l>*<m>element
Donde <l> indica "al menos" y <m> "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 " * ".
<l>#<m>element , indica al menos <l> y como maximo <m> 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 = <any 8-bit sequence of data> ; ( 0-177, 0 -127. )
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character> ; (101-132, 65.- 90.)
; (141-172, 97.-122.)
UPALPHA = <any US-ASCII uppercase letter "A" .. "Z">
LOALPHA = <any US-ASCII lowercase letter "z" .. "z">
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SP = <ASCII SP, space> ; ( 40, 32.)
HT = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 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*<any CHAR except CTLs or separators>
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 = <any CHAR, including bare ; => 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 = <any CHAR excepting <">, ; => may be folded
"\" & CR, and including
linear-white-space>
domain-literal = "[" *(dtext | quoted-pair) "]"
dtext = <any CHAR excluding "[", ; => may be folded
"]", "\" & CR, & including
linear-white-space>
comment = "(" *(ctext | quoted-pair | comment) ")"
ctext = <any CHAR excluding "(", ; => 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 = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>
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 = <A legal Internet host domain name or IP address (in
dotted-decimal form), as defined by Section 2.1 of RFC 1123>
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 = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
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 = *<TEXT, excluding CR, LF>
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