HTTP

HTTP

De TW

(Diferencias entre revisiones)
(Página nueva: {{Estado reformateado|http://www.tejedoresdelweb.com/307/article-1856.html}} {{Estado obsoleto}} {{Estado esbozo}} [ftp://ftp.isi.edu/in-notes/rfc2616.txt RFC2616] reemplaza a [htt...)
Revisión actual (16:58 1 may 2008) (editar) (deshacer)
 
Línea 1: Línea 1:
-
{{Estado reformateado|http://www.tejedoresdelweb.com/307/article-1856.html}}
 
-
 
-
{{Estado obsoleto}}
 
-
 
{{Estado esbozo}}
{{Estado esbozo}}
-
[ftp://ftp.isi.edu/in-notes/rfc2616.txt RFC2616] reemplaza a [http://www.cis.ohio-state.edu/rfc/rfc1945.txt RFC 1945]. El protocolo HTTP es:
+
[ftp://ftp.isi.edu/in-notes/rfc2616.txt RFC2616] define HTTP 1.1 y reemplaza a [http://www.cis.ohio-state.edu/rfc/rfc1945.txt RFC 1945]. El protocolo HTTP es:
-
# Stateless
+
# Sin estado, en el sentido de que ninguno de los dos, ni el cliente ni el servidor, necesita "recordar" nada entre transferencias.
-
# .Extensible, por medio de cambios en los encabezados, requests y respuestas
+
# Extensible, por medio de cambios en los encabezados, requests y respuestas.
-
# Involucra negociación entre cliente y servidor
+
# Involucra un cierto tipo de negociación entre cliente y servidor.
-
Lo importante de HTTP/1.0 es su soporte para tipos MIME, pero no toma en cuenta ni proxies, ni caching, ni conecciones persistentes o virtual hosts. HTTP/1.1 por otra parte implementa estas características, pero cuenta con una conección perfecta y no hace corrección de errores.
+
Los cambios desde HTTP/1.0 son el uso de proxies, caching, conecciones persistentes y virtual hosts.
-
El uso normal es un UserAgent que envía una cadena de requerimiento, y recibe una cadena de respuesta, o un stream. Entre ellos pueden haber proxies, gateways o túneles.
+
El uso normal es mediante un ''User Agent'' (un browser) que envía una cadena de requerimiento, y recibe una cadena de respuesta, o un stream. Entre ellos pueden haber proxies, gateways o túneles.
== Subcomponentes ==
== Subcomponentes ==
Línea 32: Línea 28:
# Quality values (algunas restricciones son más importantes que otros)ej.: de Mozilla 0.9.2: "HTTP_ACCEPT_CHARSET = ISO-8859-1, utf-8;q=0.66, *;q=0.66"
# Quality values (algunas restricciones son más importantes que otros)ej.: de Mozilla 0.9.2: "HTTP_ACCEPT_CHARSET = ISO-8859-1, utf-8;q=0.66, *;q=0.66"
-
# Chunked transfers (rangos).
+
# Chunked transfers (rangos)
== Mensajes ==
== Mensajes ==
Línea 62: Línea 58:
* 3xx: Ok, pero ... ej. Redirect
* 3xx: Ok, pero ... ej. Redirect
* 4xx: Requerimiento con errores ej.: Not Found
* 4xx: Requerimiento con errores ej.: Not Found
-
* 5.5xx: Respuesta con errores ej.: Server Error
+
* 5xx: Respuesta con errores ej.: Server Error
Las aplicaciones deben entender al menos el primer dígito de la respuesta. Pueden no entender el resto, y eso da mucha flexibilidad al protocolo (ej.: un programa de ajedrez entre un cliente y un servidor: 285 jugada aceptada, 482 jugada ilegal, 196 estoy pensando, 387 jaque mate)
Las aplicaciones deben entender al menos el primer dígito de la respuesta. Pueden no entender el resto, y eso da mucha flexibilidad al protocolo (ej.: un programa de ajedrez entre un cliente y un servidor: 285 jugada aceptada, 482 jugada ilegal, 196 estoy pensando, 387 jaque mate)

Revisión actual

Este artículo es un esbozo y necesita ser expandido

RFC2616 define HTTP 1.1 y reemplaza a RFC 1945. El protocolo HTTP es:

  1. Sin estado, en el sentido de que ninguno de los dos, ni el cliente ni el servidor, necesita "recordar" nada entre transferencias.
  2. Extensible, por medio de cambios en los encabezados, requests y respuestas.
  3. Involucra un cierto tipo de negociación entre cliente y servidor.

Los cambios desde HTTP/1.0 son el uso de proxies, caching, conecciones persistentes y virtual hosts.

El uso normal es mediante un User Agent (un browser) que envía una cadena de requerimiento, y recibe una cadena de respuesta, o un stream. Entre ellos pueden haber proxies, gateways o túneles.

Tabla de contenidos

Subcomponentes

Básicos:

  1. Paso de versión del protocolo (también: sirve para backwards compatibility).
  2. Inclye URLs, y cual es la forma normal de una URL.
  3. Formato para fechas y para deltas de tiempo.

Negociación de cotenido:

  1. Sets de caracteres y codificaciones (ej.: compresión).
  2. Soporte para tipos MIME
  3. Lenguajes

Y algunos componentes más esotéricos:

  1. Quality values (algunas restricciones son más importantes que otros)ej.: de Mozilla 0.9.2: "HTTP_ACCEPT_CHARSET = ISO-8859-1, utf-8;q=0.66, *;q=0.66"
  2. Chunked transfers (rangos)

Mensajes

Los mensajes tienen varios encabezados de la forma nombre=valor y un cuerpo de mensaje. Se dividen en mensajes de requerimiento y mensajes de respuesta.

Existen algunos encabezados compartidos:

  1. Cache-Control
  2. Connection (close,persistent)
  3. Date
  4. Pragma

Request messages

Comienzan con una línea del tipo "MÉTODO URL VERSION", como "GET / HTTP/1.1". A continuación siguen normalmente uno o varios de los siguientes encabezados:

  1. Host (para virtualhosts)
  2. Authorization (para suplir credenciales)
  3. Accept-* (aceptar lenguaje, mime, etc.)
  4. User-Agent (identificar el browser)

Response messages

Comienzan con una línea del tipo "VERSIÓN CÓDIGO MENSAJE", como "HTTP/1.1 200 OK". Los códigos se agrupan por familias, de la siguiente manera:

  • 1xx: Informacional, continuar.
  • 2xx: Ok
  • 3xx: Ok, pero ... ej. Redirect
  • 4xx: Requerimiento con errores ej.: Not Found
  • 5xx: Respuesta con errores ej.: Server Error

Las aplicaciones deben entender al menos el primer dígito de la respuesta. Pueden no entender el resto, y eso da mucha flexibilidad al protocolo (ej.: un programa de ajedrez entre un cliente y un servidor: 285 jugada aceptada, 482 jugada ilegal, 196 estoy pensando, 387 jaque mate)

Conección persistente

Pipelining, negociación de conección persistente. Además HTTP/1.1 incluye un protocolo de caching y un modelo de expiración para ese caching, que indica si la expiración debe ser explícita, implícita, etc.

Obtenido de "http://www.tejedoresdelweb.com/w/HTTP"