Diferencia entre revisiones de «Protocolo de transferencia de hipertexto»
m Revertido a la revisión 29029272 hecha por Diegusjaimes. (TW) |
|||
Línea 18: | Línea 18: | ||
== Transacciones HTTP == |
== Transacciones HTTP == |
||
⚫ | Una [[transacción]] HTTP ES DONDE CAPERUSITA ROJA TENIA SU CASITA 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. |
||
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. |
|||
⚫ | |||
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—. |
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—. |
Revisión del 20:49 18 sep 2009
Plantilla:Infobox protocolo de red El protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) es el protocolo usado en cada transacción de la Web (WWW). HTTP fue desarrollado por el consorcio W3C y la IETF, 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 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 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 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 ES DONDE CAPERUSITA ROJA TENIA SU CASITA 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 librería/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
- Se abre una conexión al host www.example.com, puerto 80 que es el puerto por defecto para HTTP.
- 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>
import java.applet.*; import java.awt.*; import java.util.*; import java.text.DateFormat; /*public*/ class Reloj extends Applet implements Runnable {private Thread hilo=null; private Font fuente; private String horaActual="00:00:00"; public void init() { fuente= new Font("Arial",Font.BOLD,24); }//fin del metodo init public void start() { if(hilo==null)// si hilo esta inactivo { hilo=new Thread(this,"Reloj"); hilo.start(); }// fin del if }//fin del metodo start public void run() { Thread hiloActual=Thread.currentThread(); while(hilo==hiloActual) {//obtener la hora actual Calendar cal=Calendar.getInstance(); Date hora=cal.getTime(); DateFormat df=DateFormat.getTimeInstance(); horaActual=df.format(hora); repaint(); try{ Thread.sleep(1000); }// fin del bloque try catch(InterruptedException e){}// fin del catch }//fin de la sentencia will }//fin del metodo run public void paint(Graphics g) {//Dibujar un rectangulo alrededor del contenedor g.draw3DRect(1,1,getSize().width-3,getSize().height-3,true); //establecer fuente g.setFont(fuente); //mostrar la hora g.drawString(horaActual,14,40); }//fin del metodo paint public void stop() {hilo=null; }//finn del metodo stop }// fin de la clase Reloj
este es un ejemplo de un reloj digital
Primeros Servidores
Códigos de respuesta
Son códigos de tres dígitos (vea también Anexo:Códigos de estado HTTP):
- 1xx Mensajes
N° - 100 111 Conexión rechazada
- 2xx Operación exitosa
N° 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
N° 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
N° 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 Proxy requerido 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
N° 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
Enlaces externos
- RFC-2616
- HTTP - Hypertext Transfer Protocol. W3C
- HTTP Made Really Easy. byJames Marshall, 1997
- Validación de HTTP Headers Verificación de URL Online