El protocolo HTTP:
Hypertext Transfer Protocol
Hypertext Transfer Protocol
Introducción al protocolo HTTP
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 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.
(Click en iniciar animación)
* 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.
Comunicación entre el navegador y el servidor
La comunicación entre el navegador y el servidor se lleva a cabo en dos etapas:
* El navegador realiza una solicitud HTTP
* El servidor procesa la solicitud y después envía una respuesta HTTP
En realidad, la comunicación se realiza en más etapas si se considera el procesamiento de la solicitud en el servidor. Dado que sólo nos ocupamos del protocolo HTTP, no se explicará la parte del procesamiento en el servidor en esta sección del artículo. Si este tema les interesa, puede consultar el articulo sobre el tratamiento de CGI.
Ejemplo de un diálogo HTTP
Para obtener un recurso con el URL
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:
La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página web:
Los códigos de respuesta
Son los códigos que se ven cuando el navegador no puede mostrar la página solicitada. El código de respuesta está formado por tres dígitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error.
1xx: Respuestas informativas
Petición recibida, continuando proceso.
Esta clase de código de estatus indica una respuesta provisional, que consiste únicamente en la línea de estatus y en encabezados opcionales, y es terminada por una línea vacía. Desde que HTTP/1.0 no definía códigos de estatus 1xx, los servidores no deben enviar una respuesta 1xx a un cliente HTTP/1.0, excepto en condiciones experimentales.
* 100 Continúa
* 101 Conmutando protocolos
* 102 Procesando
2xx: Peticiones correctas
Esta clase de código de estado indica que la petición fue recibida correctamente, entendida y aceptada.
* 207 Estado múltiple (Multi-Status, WebDAV):
El cuerpo del mensaje que sigue es un mensaje XML y puede contener algún número de códigos de respuesta separados, dependiendo de cuántas sub-peticiones sean hechas.
3xx: Redirecciones
El cliente tiene que tomar una acción adicional para completar la petición.
Esta clase de código de estado indica que una acción subsecuente necesita efectuarse por el agente de usuario para completar la petición. La acción requerida puede ser llevada a cabo por el agente de usuario sin interacción con el usuario si y sólo si el método utilizado en la segunda petición es GET o HEAD. El agente de usuario no debe redirigir automáticamente una petición más de 5 veces, dado que tal funcionamiento indica usualmente un Bucle infinito.
* 305 Utilice un proxy (desde HTTP/1.1):
Muchos clientes HTTP (como Mozilla e Internet Explorer) no se apegan al estándar al procesar respuestas con este código, principalmente por motivos de seguridad.
* 306 Cambie de proxy:
Esta respuesta está descontinuada.
* 307 Redirección temporal (desde HTTP/1.1):
Se trata de una redirección que debería haber sido hecha con otra URI, sin embargo aún puede ser procesada con la URI proporcionada. En contraste con el código 303, el método de la petición no debería ser cambiado cuando el cliente repita la solicitud. Por ejemplo, una solicitud POST tiene que ser repetida utilizando otra petición POST.
4xx Error por parte del cliente
La solicitud contiene sintaxis incorrecta o no puede procesarse.
La intención de la clase de códigos de respuesta 4xx es para casos en los cuales el cliente parece haber errado la petición. Excepto cuando se responde a una petición HEAD, el servidor debe incluir una entidad que contenga una explicación a la situación de error, y si es una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de solicitud (como GET o POST). Los agentes de usuario deben desplegar cualquier entidad al usuario. Estos son típicamente los códigos de respuesta de error más comúnmente encontrados.
* 405 Método no permitido:
Una petición fue hecha a una URI utilizando un método de solicitud no soportado por dicha URI; por ejemplo, cuando se utiliza GET en una forma que requiere que los datos sean presentados vía POST, o utilizando PUT en un recurso de sólo lectura.
* 406 No aceptable
* 407 Autenticación Proxy requerida
* 408 Tiempo de espera agotado:
El cliente falló al continuar la petición - excepto durante la ejecución de videos Adobe Flash cuando solo significa que el usuario cerró la ventana de video o se movió a otro.
* 409 Conflicto
* 410 Ya no disponible:
ndica que el recurso solicitado ya no está disponible y no lo estará de nuevo. Este código debería ser utilizado cuando un recurso haya sido quitado intencionalmente; sin embargo, en la práctica, un código 404 No encontrado es expedido en su lugar.
* 411 Requiere longitud
* 412 Falló precondición
* 413 Solicitud demasiado larga
* 414 URI demasiado larga
* 415 Tipo de medio no soportado
* 416 Rango solicitado no disponible:
El cliente ha preguntado por una parte de un archivo, pero el servidor no puede proporcionar esa parte, por ejemplo, si el cliente preguntó por una parte de un archivo que está más allá de los límites del fin del archivo.
* 417 Falló expectativa
* 421 Hay muchas conexiones desde esta dirección de internet
* 422 Entidad no procesable (WebDAV - RFC 4918):
La solicitud está bien formada pero fue imposible seguirla debido a errores semánticos.
* 423 Bloqueado (WebDAV - RFC 4918):
El recurso al que se está teniendo acceso está bloqueado.
* 424 Falló dependencia (WebDAV - RFC 4918):
La solicitud falló debido a una falla en la solicitud previa.
* 425 Colección sin ordenar:
Definido en los drafts de WebDav Advanced Collections, pero no está presente en "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol" (RFC 3648).
* 426 Actualización requerida (RFC 2817):
EEl cliente debería cambiarse a TLS/1.0.
* 449 Reintente con:
Una extensión de Microsoft: La petición debería ser reintentada después de hacer la acción apropiada.
5xx Errores de servidor
El servidor falló al completar una solicitud aparentemente válida.
Los códigos de respuesta que comienzan con el dígito "5" indican casos en los cuales el servidor tiene registrado aún antes de servir la solicitud, que está errado o es incapaz de ejecutar la petición. Excepto cuando está respondiendo a un método HEAD, el servidor debe incluir una entidad que contenga una explicación de la situación de error, y si es una condición temporal o permanente. Los agentes de usuario deben desplegar cualquier entidad incluida al usuario. Estos códigos de repuesta son aplicables a cualquier método de petición.
* 505 Versión de HTTP no soportado
* 506 Variante también negocia (RFC 2295)
* 507 Almacenamiento insuficiente (WebDAV - RFC 4918)
* 509 Límite de ancho de banda excedido:
Este código de estatus, mientras que es utilizado por muchos servidores, no es oficial.
* 510 No extendido (RFC 2774)
Yapa!
link: http://www.videos-star.com/watch.php?video=UjZQGRATlwA
Ojala al equipo de Taringa! no le pase lo mismo
EJEMPLO ERROR 403
Este error fue motivo de este post
Fuente 1
Fuente 2
Fuente 3
Fuente 4
Eso fue todo cualquier problema/duda/sugerencia dejen un comentario
Saludos y que tengan un buen dia.
¿Queres torrents en taringa?, apoya mi otro post hace click
-