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, el más importante de ellos es 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 guion ( - ) 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 HTP_ACPT y HTP_R_AEN.
HT_AEP'. 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.
HTT_USR_AET. El navegador que utiliza el cliente para realizar la petición. El formato general para esta variable es: software/versión biblioteca/versión.
Métodos de petición
HEAD
Pide una 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 /imagen/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 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 diagnóstico.
OPTIONS
Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico
CONNECT
Códigos de respuesta
- 1xx Mensajes
| N° | Descripció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 Redireción
| N° | Descripción |
| 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 |
| 402 | Pago requerido |
| 403 | Prohibido |
| 404 | No encontrado |
| 409 | Conflicto |
| 410 | Ya no disponible |
| 412 | Falló precondición |
- 5xx Error del servidor
| N° | Descripción |
| 500 | Error interno |
| 501 | No implementado |
| 502 | Pasarela incorrecta |
| 503 | Servicio nodisponible |
| 504 | Tiempo de espera de la pasarela agotado |
| 505 | Versión de HTTP no soportada |
No hay comentarios:
Publicar un comentario