Diferencia entre revisiones de «Protocolo de transferencia de hipertexto»

De Wikipedia, la enciclopedia libre
Contenido eliminado Contenido añadido
Diegusjaimes (discusión · contribs.)
m Revertidos los cambios de 190.247.148.43 (disc.) a la última edición de VolkovBot
Línea 17: Línea 17:


HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las [[cookie]]s, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.
HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las [[cookie]]s, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

== Transacciones HTTP ==
Una [[transacción]] HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado.

El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario.

Un encabezado es un bloque de datos que precede a la información propiamente dicha, por lo que muchas veces se hace referencia a él como [[metadato]] —porque tiene datos sobre los datos—.

Si se reciben líneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de [[CGI]] con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carácter guión ( - ) del nombre del encabezado se convierte a caracteres "_".

El servidor puede excluir cualquier encabezado que ya esté procesado, como ''Authorization'', ''Content-type'' y ''Content-length''. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algún límite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT.

*'''HTTP_ACCEPT'''. Los [[Multipurpose Internet Mail Extensions|tipos MIME]] que el cliente aceptará, dado los encabezados HTTP. Otros protocolos quizás necesiten obtener esta información de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificación HTTP: tipo, tipo.

*'''HTTP_USER_AGENT'''. El navegador que utiliza el cliente para realizar la petición. El formato general para esta variable es: software/versión biblioteca/versión.

El servidor envía al cliente:

*Un código de estado que indica si la petición fue correcta o no. Los códigos de error típicos indican que el archivo solicitado no se encontró, que la petición no se realizó de forma correcta o que se requiere autenticación para acceder al archivo.
*La información propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir [[multimedia]], como gráficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP.
*Información sobre el objeto que se retorna.

Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de
ellos sólo tienen sentido en una dirección.

== Versiones ==
HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta.

;0.9
: Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.
; HTTP/1.0 (mayo [[1996]])
: Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.
; HTTP/1.1 (junio [[1999]])<ref>
Enero de [[1997]]. Se publica la primera versión de la especificación HTTP/1.1 <!-- {{Inet-note-ref|type=rfc|id=2068|text=RFC 2068}} --></ref><ref>
Junio de [[1999]]. Publicada la última versión de la especificación HTTP/1.1 <!-- {{Inet-note-ref|type=rfc|id=2616|text=RFC 2616}} --></ref>

: Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También permite al cliente enviar múltiples peticiones a la vez (pipelining) lo que hace posible eliminar el [[RTT|tiempo de Round-Trip delay]] por cada petición.

; HTTP/1.2
: Los primeros borradores de [[1995]] del documento ''PEP — an Extension Mechanism for HTTP'' (el cuál propone el [[Protocolo de Extensión de Protocolo]], abreviado PEP) los hizo el [[World Wide Web Consortium]] y se envió al [[Internet Engineering Task Force]]. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2.<ref>[http://www.w3.org/TR/WD-http-pep-951122.html] ''PEP: An Extension Mechanism for HTTP''. Cita: "For experimental purposes, PEP-compatibility is equated with HTTP/1.2."</ref> En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774 (experimental), ''HTTP Extension Framework'', incluye en gran medida a PEP. Se publicó en febrero de [[2000]].


== Ejemplo de un diálogo HTTP ==
== Ejemplo de un diálogo HTTP ==

Revisión del 14:42 5 may 2010

Hyper text Transfer Protocol
(HTTP)
Familia Familia de protocolos de Internet
Función Transferencia de hipertexto
Última versión 1.2
Puertos 80/TCP
Ubicación en la pila de protocolos
Aplicación HTTP
Transporte TCP
Red IP
Estándares
RFC 1945 (HTTP/1.0, 1996)
RFC 2616 (HTTP/1.1, 1999)
RFC 2774 (HTTP/1.2, 2000)

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616, que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc.

HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Transacciones HTTP

Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado.

El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario.

Un encabezado es un bloque de datos que precede a la información propiamente dicha, por lo que muchas veces se hace referencia a él como metadato —porque tiene datos sobre los datos—.

Si se reciben líneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carácter guión ( - ) del nombre del encabezado se convierte a caracteres "_".

El servidor puede excluir cualquier encabezado que ya esté procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algún límite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT.

  • HTTP_ACCEPT. Los tipos MIME que el cliente aceptará, dado los encabezados HTTP. Otros protocolos quizás necesiten obtener esta información de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificación HTTP: tipo, tipo.
  • HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la petición. El formato general para esta variable es: software/versión biblioteca/versión.

El servidor envía al cliente:

  • Un código de estado que indica si la petición fue correcta o no. Los códigos de error típicos indican que el archivo solicitado no se encontró, que la petición no se realizó de forma correcta o que se requiere autenticación para acceder al archivo.
  • La información propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como gráficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP.
  • Información sobre el objeto que se retorna.

Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos sólo tienen sentido en una dirección.

Versiones

HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta.

0.9
Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.
HTTP/1.0 (mayo 1996)
Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.
HTTP/1.1 (junio 1999)[1][2]
Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También permite al cliente enviar múltiples peticiones a la vez (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada petición.
HTTP/1.2
Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cuál propone el Protocolo de Extensión de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envió al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2.[3]​ En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se publicó en febrero de 2000.

Ejemplo de un diálogo HTTP

Para obtener un recurso con el URL http://www.example.com/index.html

  1. Se abre una conexión al host www.example.com, puerto 80 que es el puerto por defecto para HTTP.
  2. Se envía un mensaje en el estilo siguiente:
 GET /index.html HTTP/1.1
 Host: www.example.com
 User-Agent: nombre-cliente
 [Línea en blanco]

La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página web:

HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221

<html>
<body>
<h1>Página principal de tuHost</h1>
(Contenido)
  .
  .
  .
</body>
</html>

Primeros Servidores

Métodos de Petición

Un pedido HTTP usando telnet. El pedido (request), cabeceras de respuesta (response headers) y el cuerpo de la respuesta (response body) estan resaltados.

HTTP define 8 métodos (algunas veces referido como "verbos") que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.

HEAD
Pide que la respuesta idéntica a la que correspondería a una petición GET, pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de meta-información escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.
GET
Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.
Ejemplo:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png
Ejemplo con parámetros:
/index.php?page=main&lang=es
POST
Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.
PUT
Sube, carga o realiza un upload de una de un recurso especificado (archivo), es el camino más eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida con el servidor.
La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1
DELETE
Borra el recurso especificado.
TRACE
Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnostico.
OPTIONS
Devuelve los método HTTP que el servidor soporta para un URL especifico.Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante peticion en lugar de un recurso especifico
CONNECT

Códigos de respuesta

Son códigos de tres dígitos (vea también Anexo:Códigos de estado HTTP):

  • 1xx Mensajes
- 100 111 Conexión rechazada
  • 2xx Operación exitosa
Descripción
200 OK
201-203 Información no oficial
204 Sin Contenido
205 Contenido para recargar
206 Contenido parcial
  • 3xx Redirección hacia otro URL
Descripción
300 Múltiples posibilidades
301 Mudado permanentemente
302 Encontrado
303 Vea otros
304 No modificado
305 Utilice un proxy
307 Redirección temporal
  • 4xx Error por parte del cliente
Descripción
400 Solicitud incorrecta
401 No autorizado
402 Pago requerido
403 Prohibido
404 No encontrado
405 Método no permitido
406 No aceptable
407 Autenticación requerida
408 Tiempo de espera agotado
409 Conflicto
410 Ya no disponible
411 Requiere longitud
412 Falló precondición
413 Entidad de solicitud demasiado larga
414 URL de solicitud demasiado largo
415 Tipo de medio no soportado
416 Rango solicitado no disponible
417 Falló expectativa
  • 5xx Error por parte del servidor
Descripción
500 Error interno
501 No implementado
502 Pasarela incorrecta
503 Servicio no disponible
504 Tiempo de espera de la pasarela agotado
505 Versión de HTTP no soportada

Referencias

  1. Enero de 1997. Se publica la primera versión de la especificación HTTP/1.1
  2. Junio de 1999. Publicada la última versión de la especificación HTTP/1.1
  3. [1] PEP: An Extension Mechanism for HTTP. Cita: "For experimental purposes, PEP-compatibility is equated with HTTP/1.2."

Enlaces externos