HTTP explicado: El protocolo de transferencia de hipertexto, parte 1

Esto es parte de una serie más grande titulada, “Cómo programar cualquier cosa: Internet” (Enlace para venir)

El protocolo de transferencia de hipertexto

Muchos de nosotros en estos días realmente no prestan mucha atención a esos prefijos enigmática a nuestras URL que nos indican a nuestras páginas web favoritas, ha sido relegado a un poco de la magia moderna que damos por sentado. De hecho, muchos navegadores ahora ocultan “http: //” o “https: //” de nosotros mientras exploramos la web por completo. Sin embargo, cuando se utiliza un navegador web para navegar por la “World Wide Web” como Tim-Berners Lee titulado su proyecto seminal de hipertexto, usamos el esquema http URI, y el protocolo resultante todo el tiempo, para casi todo. (No sé lo que es un URI o URI esquema? Tengo un tutorial explicando todas las cosas URI, URL, URN, y sus respectivos componentes en Anatomía de un URI) Pero, ¿cómo funciona? Qué significa eso?

¿Qué es el hipertexto?

El hipertexto es un concepto abstracto que está íntegramente relacionado con el texto “tradicional”. “Hyper-” como prefijo en inglés viene del griego “ὑπερ” (pronunciado, como se da en el IPA clásico: / hupér /, o en el IPA más moderno: / hypér /). En latín podríamos pensar en la palabra “super”, y en algo más germánico podríamos considerar el prefijo “uber”, como en el übermensch de la filosofía nietzscheana. La relación es similar, de hecho, al uso de Nietzsche de ella, donde el übermensch es un hombre superior que ha trascendido a la humanidad simple, el hipertexto es un texto que ha trascendido u oercome las restricciones del texto escrito, sobre todo su naturaleza lineal.

La forma clave más importante de lograr esto es mediante la posibilidad de integrar “hipervínculos” (como han llegado a ser conocido) en el contenido tanto textual y gráfico, que tiene una relación con otro pedazo de contenido. Al interactuar con este enlace incrustado, el lector puede acceder de inmediato a información esperanzadamente pertinente, y en algunos usos artísticos a otros “caminos”, a lo que se está discutiendo en pata. Esta capacidad de “interactuar” con el texto y los medios de comunicación, aunque sea un simple toque, selección o “clic” es imprescindible a la capacidad de integrar tales enlaces en el texto, y por lo tanto, el hipertexto como lo conocemos debe ser mostrado En dispositivos capaces de tal interacción.

Por ejemplo, el “memex” prototípico acuñado e inventado por Vannevar Bush (aunque “memex” fue acuñado después de la publicación) en su ensayo Mechanization and the Record en 1939 (que más tarde sería reelaborado y ampliado como un artículo publicado en The Atlantic en julio de 1945 Titulado “Como Podemos Pensar”). Vannevar expresó su preocupación por los destructivos logros de la ciencia de la época (un acontecimiento contemporáneo fueron los bombardeos atómicos de Hiroshima y Nagasaki, algo que Vannevar había estado involucrado en la iniciación y administración temprana del Proyecto Manhattan) y esperaba a los científicos de posguerra enfocados en promover Comprensión y otras tales buena voluntad. Esto conducía a una explosión de la información, cuya naturaleza podría obstaculizar o dificultar la búsqueda científica. Imaginaba básicamente un dispositivo como un mueble que podía asociar varios registros (microfilms) usando relaciones, y que la gente podía examinar y producir “senderos” donde van de un registro a otro a través de enlaces relacionales. También imaginó alguna forma de transferir información de un memex a otro. Su esperanza era que “aparecían formas totalmente nuevas de enciclopedias, listas con una malla de senderos asociativos que corrían a través de ellas, listos para ser arrojados al memex y allí amplificados”. (“Como Podemos Pensar“) No sólo que propuso una cierta memoria colectiva usando la máquina haciendo que el conocimiento sea más accesible. ¿Suena familiar? (Piense: Wikipedia) La idea es que usted podría usar códigos para decirle a la máquina que saltar y extraer la información en “al azar”, o en la construcción de un rastro. Suena como un hipervínculo para mí.

Las cosas iban a progresar a partir de 1945 a un ritmo bastante rápido, sin embargo, y el 9 de diciembre de 1968 Douglas Engelbart puso en “La Madre de Todos los Demos” en la ACM / IEEE – Computer Society Fall Conferencia Computer conjunta en San Francisco. En esta demostración, una presentación en vivo de 90 minutos demostró un ratón de computadora, pantallas de mapa de bits y encima de esas ventanas, gráficos, hipertexto, videoconferencia, vinculación de archivos dinámicos, control de revisión y un editor colaborativo en tiempo real. Todo esto se demostró en un único sistema llamado NLS (el sistema de línea oN). Esta demostración inició el trabajo que Xerox hizo hacia interfaces gráficas de usuario e influyó mucho tanto en los sistemas operativos Macintosh de Apple como en los sistemas operativos Microsoft Windows en los años ochenta. Recuerde, esta demostración ocurrió en 1968. Divertido bastante, antes de la demostración mucho de la comunidad de la informática vio Douglas como algo de un “crisol de la grieta”. (La madre de todas las demostraciones – 150 años delante de su tiempo).

¡Con estas máquinas hermosas que vienen en ser, una máquina como un memex podría ser hecha potencialmente! Es por eso que en 1989 Tim Berners-Lee, un científico en el CERN, propuso un nuevo proyecto que él llamó “WorldWideWeb”. La idea era que pudiéramos construir un sistema que ofreciera un intercambio de información simple e inmediato entre los físicos que trabajan en instituciones académicas. El escribio:

HyperText es una forma de vincular y acceder a información de varios tipos como una red de nodos en los que el usuario puede navegar a voluntad. Potencialmente, HyperText proporciona una interfaz de usuario única para muchas clases grandes de información almacenada, tales como informes, notas, bases de datos, documentación de la computadora y ayuda de sistemas en línea. Proponemos la implementación de un esquema simple para incorporar varios servidores diferentes de información almacenada en máquina ya disponible en el CERN, incluyendo un análisis de los requisitos para las necesidades de acceso a la información por experimentos … Un programa que proporciona acceso al mundo hipertexto que llamamos navegador. – T. Berners-Lee, R. Cailliau, 12 de noviembre de 1990, CERN

Finalmente, en 1992, Lynx nació como un navegador de Internet temprano. Su capacidad para proporcionar enlaces de hipertexto dentro de los documentos que podrían llegar a los documentos en cualquier lugar en Internet comenzó la creación de la Web en Internet. De hecho, Lynx fue mi primer navegador web que usé como parte del sistema de terminales de ACLIN en el que podía conectarme en mi biblioteca local. En realidad, de hecho, utilicé el sistema de números 800 de la biblioteca ACLIN para telnet, lanzar Lynx y luego navegar a MUCKs y MUDs de interés … era mi única conexión con el mundo exterior antes de AOL!

Actualmente, en 2017, después de que las ideas y las invenciones de Douglas llegaran al ámbito de la computación personal desde el Xerox Alto hasta el inmensamente popular Apple Macintosh, este hipertexto de interactividad requiere generalmente se consigue con ordenadores: las pantallas muestran el hipertexto y el usuario utiliza algún mecanismo de entrada Como una pantalla táctil o un ratón, para seleccionar e interactuar con el enlace incrustado. Y los enlaces sirven en gran parte la función que un memex debía servir, extrayendo información de diversas fuentes dispares en todo el mundo en una especie de inteligencia informativa colectiva llamada World Wide Web

Nota sin embargo! No confunda HyperText como HTML. HyperText es una idea abstracta de contenido enlazado de varias maneras, donde HTML es el HyperText Markup Language. HTML es uno de los muchos medios para dar formato a la información en un sistema HyperText.

La World Wide Web es un sistema de hipertexto

Como se puede ver entonces, lo que llegó a ser la World Wide Web, es el último sistema de HyperText. Está utilizando las tecnologías World Wide Web e HyperText, como HTML y HTTP, para simplemente ver esta página y todo su contenido, incluidas las imágenes y otras técnicas. Parece que el sueño de Vannevar se convirtió en una realidad, y ahora estamos aprovechando información cada vez más explosiva en formas que son comprensibles por la sociedad y los individuos.

Comunicación de computadora a computadora

Uno de los elementos integrales de la web como la conocemos es la capacidad de comunicarse de una máquina a otra. Es decir, ¿cómo obtengo esta información de la página web de la computadora que la sostiene (wunk.me)? Esta página está formada por HTML (HyperText Markup Language), CSS (Cascading Style Sheets), JS (JavaScript) y muchas imágenes. ¿Cómo obtienen todos estos archivos, todas estas piezas de datos desde donde mi sitio web existe (en el servidor en alguna parte de una granja de servidores almacenados) en su computadora para que pueda verlo?

La conexión en red de computadoras es un tema extraordinariamente complejo y detallado, por lo que es difícil determinar exactamente cómo transmitir los protocolos y otros mecanismos y qué hacen. En resumen, Internet como la conocemos en general, pero no siempre, se ejecuta en una tecnología denominada colectivamente TCP / IP (Protocolo de Control de Transmisión / Protocolo de Internet) también llamada Internet Protocol Suite. Se divide en “capas” que operan una “encima” de la otra, es decir, dependiendo de la anterior. Comienza básicamente con la capa de enlace, luego con la capa de Internet, luego con la capa de transporte y finalmente con la capa de aplicación. Cada capa trata de conectar computadoras y enviar mensajes desde un nodo en una red a otro nodo de la red.

Hoy en día, para HTTP, afortunadamente solo usaremos y nos centraremos en la capa de aplicación. Esta es la “capa” o entorno donde las aplicaciones pueden simplemente conectarse a un puerto de otra máquina y “automágicamente” enviar datos a ese puerto, y entonces dicho puerto recibirá “automágicamente” esa información y cualquier programa que esté escuchando en ese puerto Procesar los datos dados. El ejemplo más interactivo y barebones de esta capa es una conexión Telnet básica. Usted puede “Telnet” a un puerto particular usando su línea de comando, mecanografiar las letras y la vuelta, y voilà esos caracteres se envían al puerto de esa computadora. HTTP funciona con este tipo de conexión y, para que se muestre más adelante, puede establecer una conexión Telnet al puerto de un servidor web (como wunk.me:80), escribir manualmente una solicitud HTTP y recibir los datos sin procesar HTTP Respuesta en la pantalla del terminal. Esto es esencialmente lo que su navegador web hace “detrás de las escenas”.

¿Qué es un protocolo?

Se puede pensar en un protocolo de varias maneras. Un protocolo en términos de comunicación de redes informáticas es simplemente un acuerdo sobre el formato de los datos dados, su orden de presentación y los algoritmos producidos para interpretar esos datos. Un protocolo no se refiere necesariamente realmente a lo que se está comunicando, aunque a veces lo hace, pero se centra más en cómo se comunica algo. En cierto modo, las lenguas escritas y habladas son forma de un protocolo. El orden de los términos y los significados de los conjuntos de sonidos en cada idioma son diferentes, ya menos que dos partes hayan acordado hablar los mismos idiomas, para mantenerlo simple, no hay comunicación. O digamos que usted y su mejor amigo deciden que quieren enviar mensajes entre ellos, pero no quieren que nadie lea esos mensajes entre ellos. Así que usted decide utilizar un método de encriptación, retorciendo sus mensajes antes de enviarlos. Su amigo en el extremo de recepción tiene un algoritmo o método de ungarbling los mensajes … sin el cual el mensaje no significaría nada. En este sentido, usted tiene un protocolo de cifrado en su proceso de comunicación.

Los protocolos también pueden existir fuera de este contexto y ayudan a decir a los ordenadores y al hardware intermediario cómo pasar un mensaje del punto A al punto B. En este caso, el acuerdo es sobre cómo los datos dados serán enrutados de máquina a máquina, Como las reglas que un operador de teléfono pudo haber seguido en los días tempranos para conectar dos partidos.

Como pueden ver los protocolos son encapsulaciones de procesos de comunicación y de hecho se pueden comparar con lenguajes de programación en el sentido de que son encapsulaciones de procesos de computación. Encuentro que la analogía es abstracta en el mejor de los casos, pero teóricamente comienza a desmoronarse cuando se considera lo que un lenguaje de programación puede hacer fuera del contexto de un protocolo.

HTTP, HyperText Transfer Protocol, se compone de reglas de formato específicas que indican al remitente o al receptor varias informaciones. En HTTP, un “cliente” envía una solicitud a otra máquina. Esa máquina, el “servidor”, procesa la solicitud que ha recibido y envía una respuesta al cliente. En este caso, la solicitud y la respuesta tienen que ver con piezas de información que se recuperarán, como archivos que contienen HTML, CSS, JS, JPG, PNG, etc.

Servidor y Cliente: Relaciones con Computadoras

Pensé en tomar un momento para comentar sobre la relación “cliente / servidor” de la que se habla tan a menudo en redes de computadoras y protocolos de comunicación. Durante bastante tiempo encontré la tenue identidad de si una computadora era un servidor o un cliente una cosa muy confusa. Por un lado, no entendía que los roles podrían cambiar dependiendo del contexto, y en algunos casos un servidor puede actuar como un cliente y un cliente como un servidor. O que una computadora podría ser tanto un servidor como un cliente. Vamos a aclarar esto …

Finalmente me di cuenta de que en términos de “servidor” y “cliente” realmente se reduce a cómo consideramos una sola comunicación. Es decir, cada instancia de una comunicación establece quién / qué es el servidor, y quién / qué el cliente. En la mayoría de las conversaciones cerradas, especialmente en HTTP, donde todo es una solicitud o una respuesta, envía una solicitud de información (básicamente, haga una pregunta) y la otra entidad contesta su pregunta con una respuesta. La entidad que envía una solicitud de información (o solicitud de acción como veremos) es el cliente en cualquier comunicación dada, y la entidad que envía una respuesta que contiene información es el servidor en cualquier comunicación dada. Esto se puede resumir en la siguiente imagen:

En la práctica, para HTTP, generalmente configura un programa de software llamado “servidor” como APACHE o NGINX, o incluso Lighty (lighttp), en una computadora y lo usa para “servir” páginas web a otras personas. Los programas que acceden a los servidores que utilizan HTTP (los navegadores y los clientes REST) generalmente no ejecutan sus propios servidores y actúan como clientes todo el tiempo. Sin embargo, cuando pienso en servidor y cliente, simplemente me pregunto quién está solicitando información (o una acción) y quién está proporcionando una respuesta, o comentarios.

Las muchas caras de HTTP

El propio HTTP ha tenido múltiples versiones, usualmente descritas escribiendo HTTP / #. Los documentos que estoy haciendo referencia cuando hablo de HTTP son, al igual que el tutorial de URI, los RFC que finalmente definió la segunda versión final de HTTP (HTTP / 1.1), que es en uso más amplio de hoy. Estos son RFC7230 (mensaje de sintaxis y de enrutamiento), RFC7232 (Solicitudes condicionales), RFC7233 (solicitudes de rango), RFC7234 (Caching) y RFC7235 (Autenticación). Estos documentos se llaman “Solicitud de Comentarios” que ayudan a definir la mecánica y los estándares de Internet. También hay una especificación de HTTP / 2 que se cubre en RFC7231, y es actualmente la última y última versión de HTTP para tener también un amplio apoyo.

La idea de enfoque detrás de HTTP es que es un protocolo destinado a recuperar / enviar / actuar sobre los recursos en un sistema HyperText (World Wide Web). Estos recursos se identifican y localizan mediante el uso de localizadores de recursos uniformes (o URL). Las URL usan los esquemas de Identificador de Recurso Uniforme “http” y “https”. Para más información sobre URIs, esquemas y sus estructuras, vea mi tutorial anterior. (próximamente)

La versión que estamos cubriendo aquí en profundidad es HTTP / 1.1, que es una revisión de HTTP / 1.0. La diferencia más grande y más importante entre los dos es que en HTTP / 1.0 se hace una conexión independiente al servidor para cada solicitud de recurso, que es cada archivo CSS, archivo de origen de imagen, archivo JS, etc. Esto aumenta el tiempo que tarda en Cargar una “página” completa ya que cada conexión requiere el establecimiento de una conexión TCP que en términos de tiempo de procesamiento es costosa. En HTTP / 1.1, la conexión de cliente y servidor una vez establecida se puede utilizar varias veces para descargar archivos adicionales. Sin tener que abrir múltiples conexiones, la latencia se minimiza.

Ideas de HTTP

Hay múltiples ideas que rigen la filosofía del diseño de HTTP. Algunas de estas ideas son simplemente nombres para partes del proceso y formato, mientras que otras gobiernan el contexto o la falta de contexto que tiene HTTP.

Cabeceras y carga útil

Las solicitudes HTTP y las respuestas se dividen en dos secciones: encabezados y contenido. Los encabezados son toda la información pertinente de HTTP en la solicitud y respuesta, como la versión, el método, la URL, el código de estado / error, etc. El contenido, o también conocido como la entidad, es una representación de cualquier recurso dado . Esto se traduce por ejemplo, solicito un archivo JPG, recibo un mensaje HTTP con un código de estado de 200 OK en los encabezados, y en el contenido (o entidad) todos los hermosos 1s y 0s que componen el archivo JPG. O solicito wunk.me, en la carga / contenido / entidad de la respuesta HTTP es todo el HTML que compone mi página de inicio.

Apatridia

HTTP es un protocolo sin estado. Esto significa que el único contexto que cualquier solicitud o respuesta dada tiene es su respuesta o solicitud correspondiente. Eso es. Una solicitud o respuesta no puede configurar datos que deben ser recordados o considerados en solicitudes posteriores.

Por ejemplo, no puede enviar una solicitud HTTP, tal como se define, para iniciar sesión en un servidor y, a continuación, hacer que todas las solicitudes HTTP adicionales sepan automáticamente que ha hecho esto, es decir, sin agregar información adicional.

¡Pero puedo hacerlo! Tu dices. Bueno, más o menos. Navegadores y otras tecnologías han desarrollado maneras alrededor de esto incluyendo las cookies, que no son realmente parte del estándar HTTP puro y se definen en otros RFC en otros lugares. Sin embargo, cuando tiene una cookie, el navegador envía esa información de cookies al servidor con cada solicitud HTTP que haga. Esto se debe a que sin reinscribirse en la solicitud HTTP, en el dominio HTTP, ya no existiría. Cada petición es una pizarra en blanco, sin contexto, y esto es apátrida.

La sesión HTTP

A pesar de ser apátridas, existe tal cosa como una sesión HTTP. Una sesión se define mediante una serie de transacciones de petición-respuesta de red. Un cliente HTTP inicia una solicitud a un host particular en un puerto determinado (como 80 o 8080), y el servidor en el otro extremo escucha y recibe la solicitud. A continuación, el servidor procesa esta solicitud y envía una línea de estado y un mensaje propio. De principio a fin, se trata de una sesión HTTP.

Con una conexión permanente o una conexión persistente introducida en HTTP / 1.1, el cliente puede realizar más peticiones HTTP mientras la conexión sigue abierta, en lugar de cerrar la conexión después de cada solicitud. La sesión HTTP se termina cuando la conexión se cierra (en mi opinión).

Métodos de solicitud

Cuando se forma una solicitud HTTP, su información más importante es la identificación de un recurso mediante el uso de una URL. La segunda información más importante es el “verbo” o “acción” que afectará al recurso identificado. Estos son comúnmente conocidos como “métodos” (para los programas inclinados, se puede pensar en ellos un poco como los métodos de clase). HTTP / 1.0 definieron los métodos GET, POST y HEAD, sin embargo, HTTP / 1.1 agregó OPTIONS, PUT, DELETE, TRACE y CONNECT. Técnicamente no hay límite para el número de métodos que se pueden definir, y de hecho WebDAV define 7 nuevos métodos para sí mismo. Cualquier cliente puede utilizar cualquier método, y cualquier servidor puede soportar cualquier combinación de métodos, siendo el ideal. Voy sobre los métodos abajo:

  • GET – Este método especifica que se está solicitando una representación dada de la URL indicada. De acuerdo con las especificaciones un método de solicitud GET está destinado a recuperar datos solamente. Lo que esto significa es que emitir una solicitud de método GET a un servidor no debería tener el efecto secundario de cambiar el recurso en el lado del servidor u otros datos relacionados.
  • POST – Este método pasa realmente los datos al servidor en relación con el recurso solicitado. Por ejemplo, el recurso puede ser un subproceso de comentario y una solicitud de método POST a ese recurso de subproceso de comentario agregaría un nuevo comentario al subproceso. Otro ejemplo puede ser una solicitud de método POST que contiene una imagen JPG a un perfil de usuario Instagram, haciendo que la imagen JPG se convierta en otro recurso bajo la cuenta de ese usuario. Se utiliza comúnmente para enviar datos de un formulario web a un proceso de tratamiento de datos en el servidor.
  • HEAD – Este método es exactamente igual que GET, sin embargo, en lugar de obtener la respuesta completa (que es la representación del recurso, como un archivo HTML o JPG), sólo obtiene la parte de respuesta HTTP del mensaje. Puede comprobar la meta-información HTTP utilizando esto sin pedir el archivo completo. Útil si desea obtener información HTTP en una imagen de mapa, sin transferir una imagen de mapa de 20 MB.
  • PUT – (Añadido en HTTP / 1.1) La idea aquí es que se trata de una solicitud para “cargar” o almacenar los datos en el contenido de un URI particular. Si el URI se refiere a un recurso ya existente, se modifica. Si el URI no resuelve nada en el servidor, el servidor entonces presumiblemente crearía ese recurso y lo referenciaría con el URI dado.
  • DELETE – (Añadido en HTTP / 1.1) Esto es bastante explicativo. Al igual que PUT, especifica un URI que en este caso debe ser eliminado. Es decir, cualquier registro de la misma debe ser limpiado y su almacenamiento o representación ya no existe.
  • OPTIONS – (Añadido en HTTP / 1.1) La solicitud de método OPTIONS devuelve los métodos HTTP que el servidor admite para una URL específica. Por ejemplo, puedo determinar si el servidor respondería a una solicitud PUT o POST en una URL determinada antes de que necesariamente intente enviarlas.
  • TRACE – (Añadido en HTTP / 1.1) La idea detrás de este método es que a veces queremos ver qué es exactamente el servidor de punto final está recibiendo después de nuestro mensaje se enruta en Internet. Este método hace que el servidor reimprima, o echo, la solicitud recibida de nuevo al remitente para que el cliente pueda ver si se han realizado cambios o adiciones por todas las máquinas entre.
    • Importante información de seguridad: El método TRACE se puede utilizar en lo que se conoce como un ataque de rastreo entre sitios. Se trata de una vulnerabilidad que puede exponer y conceder acceso a usuarios malintencionados a varios recursos en línea y, por lo tanto, TRACE debe estar deshabilitado en todos los servidores públicos listos para la producción (esto incluye el método TRACK, que existe en los servidores Microsoft IIS).
  • PATCH – (Añadido con RFC5789) Esto es algo así como un método PUT, excepto que en lugar de sobrescribir el recurso, sólo se aplican modificaciones parciales a la misma. Así que cambia una cosa, pero no otros. Esto sería similar a GET-ing un recurso, modificándolo, y luego PUT-ing el recurso atrás.
  • CONNECT – (Añadido en HTTP / 1.1) Este método es más técnico y de red intensiva. Es una forma de convertir la conexión de solicitud a un túnel TCP / IP transparente. Esto se hace generalmente para facilitar la comunicación SSL (Secure Sockets Layer) a través de un proxy sin cifrar.

La expectativa de servidores HTTP en todas partes es que la línea de base para un servidor de propósito general es implementar los métodos GET y HEAD. Además de eso, thehy también debe responder o implementar el método de OPTIONS también para que puedan decirle a la gente que sólo puede obtener y HEAD.

Existen algunos conceptos relacionados con los métodos de solicitud HTTP que son importantes en su diseño e implementación:

  • La seguridad – Hay métodos definidos como seguros e inseguros. Los criterios para la seguridad se basa en el hecho de que algunos de los métodos están diseñados para la recuperación de información exclusivamente. Esto significa que cualquier URL que están solicitando, nada debería “suceder” al recurso en el servidor o de otra forma que no sea enviar su representación a través de la red. Estos métodos pueden incluir HEAD, GET, OPTIONS, TRACE. Se llama seguro porque la idea es que puedes hacer arbitrariamente todo tipo de solicitudes GET al azar a un servidor, manteniendo un registro de nada incluyendo el estado del servidor, y nada será interrumpido. Desafortunadamente, esta seguridad no es requerida por las especificaciones, y la seguridad en estos términos no está garantizada en todas las implementaciones. Sin embargo, en general este es el caso, y es importante de lo contrario web spiders / robots / crawlers no podría emitir GET solicitud después de GET solicitud para indexar un sitio sin causar estragos totales. Del mismo modo, los métodos inseguros incluyen POST, PUT, DELETE y PATCH. Estos son considerados inseguros a este respecto porque su recepción / ejecución puede causar efectos secundarios en el servidor o de otra manera. Estos métodos están destinados a hacer algo, lo que puede alterar los recursos a los que se hace referencia. Por ejemplo, PUT varios archivos diferentes para el mismo URI puede resultar en una sucesión de over-writes de ese recurso, dándonos sólo el último cargado.
  • Idempotencia – Los métodos PUT y DELETE están destinados a ser idempotentes. Idempotencia en este contexto se refiere a la capacidad de “aplicar” la misma operación dos veces con el mismo resultado. Cito Wikipedia: “Una operación unaria (o función) es idempotente si, cuando se aplica dos veces a cualquier valor, da el mismo resultado que si se aplicara una vez, es decir, ƒ (ƒ (x)) ≡ ƒ (x Por ejemplo, la función de valor absoluto, donde abs (abs (x)) ≡ abs (x), es idempotente. ” Lo que esto significa básicamente es que si tuvieras que hacer varias peticiones idénticas con estos métodos, será como si sólo hicieras una solicitud. No es que obtendrá la misma respuesta del servidor, pero obtendrá el mismo resultado en el servidor con respecto a los recursos en cuestión. Dos solicitudes de método DELETE idénticas en una fila sólo deben eliminar el recurso dado una vez (la segunda vez que no se eliminará nada porque ya se habrá eliminado). Dos solicitudes de método PUT idénticas en una fila deben producir una URL con una representación de recurso (por ejemplo, imagen JPG) y no dos archivos separados en el servidor. Como HTTP es apátrida, los métodos GET, HEAD, OPTIONS y TRACE también son idempotentes.

    ¡El método POST no es idempotente! Puede ser idempotente, pero no hay absolutamente ninguna garantía. Lo que esto significa que múltiples solicitudes POST idénticas no necesariamente terminan con el mismo resultado. Por ejemplo, una solicitud POST que causa el efecto secundario de dejar un comentario en un blog, si se envía de nuevo publicará el mismo comentario de nuevo. Sin protección adecuada, haga clic en “Comprar ahora!” Puede causar una solicitud POST que cobra su tarjeta de crédito dos veces! Esta es la razón por la cual los navegadores muchas veces muestran una advertencia a un usuario cuando quieren volver a cargar una solicitud POST, lo que requeriría enviar de nuevo la solicitud POST. Aplicaciones en sí pueden ser escritos para manejar estos errores desafortunados, ya menudo lo son, pero es una consideración importante.

  • Implementación – Desafortunadamente los estándares de seguridad e idempotencia anteriores no se aplican de ninguna manera. Esto significa que un programador errante podría crear un servidor que podría desencadenar todo tipo de efectos secundarios extraños en una solicitud GET o poner un archivo adicional sin sobrescribir el anterior en cada solicitud PUT. Depende del programador para garantizar la corrección de su sistema y para asegurarse de que construyen algo que un usuario asumir no se deshacerse inmensamente.

Códigos de estado

Las respuestas HTTP están realmente formateadas técnicamente diferentes a las solicitudes HTTP. En lugar de un método definido en los encabezados HTTP de la respuesta, tiene lo que se denomina Código de estado HTTP. Esto ha sido cierto desde HTTP / 1.0. Usted ha visto muy a menudo el más famoso de estos códigos del estado a menudo, particularmente en los días anteriores del Internet, que siendo 404. Un código de estado esencialmente es un número de tres dígitos seguido por una frase (la frase de la razón). Así que en nuestro ejemplo, probablemente has visto 404 No Encontrado a menudo. Disfruto especialmente 403 Prohibido. Oooh, verboten!

El primer dígito del código determina la clasificación del código de estado. De esta forma, pueden utilizarse códigos de estado personalizados, aunque existen muchos códigos de estado estandarizados. Una aplicación más probable es personalizar la “frase de razón” con equivalentes que son aplicables a esa ubicación o aplicación a discreción del programador. Esto se debe principalmente a que el código de estado de una respuesta HTTP está destinado a ser leído tanto por máquinas como por seres humanos, el código de 3 dígitos es para el ordenador / programa, mientras que la frase de razón es para el humano.

El código más utilizado es el código de estado OK 200, que indica que todo funciona correctamente y que no hay redirecciones ni errores. Los códigos de 3 dígitos suben a 599 y se pueden clasificar de la siguiente manera:

  • 1XX – Respuestas Informativas
  • 2XX – Respuestas exitosas
  • 3XX – Notificaciones de redireccionamiento
  • 4XX – Error del cliente
  • 5XX – Error del Servidor

Intermediarios

Cuando una solicitud HTTP se envía a Internet para ser pasado alrededor y finalmente encontrar su destino, puede pasar a través de otros servidores que sirven a propósitos particulares con respecto a HTTP antes de llegar a su lugar final. Tres intermediarios HTTP comunes incluyen el “proxy”, el “gateway” y el “tunnel”. Estos no están vinculados a una máquina entera, porque un único dispositivo intermediario puede actuar como un proxy, una pasarela o un túnel en un momento dado dependiendo de la petición. Estos intermediarios están más allá del alcance de este artículo y obtener más en las metodologías de red y configuración de red. Hay un cuarto “tipo” de intermediario a considerar y estos son intermediarios de red que pueden actuar en “capas inferiores” (ver arriba) del protocolo de red, filtrando o redirigiendo tráfico sin conocimiento o permiso. Este es un ataque de hombre en el medio desde el punto de vista del estándar HTTP.

Almacenamiento en caché

Un cliente, un servidor, un intermediario, etc. pueden emplear un sistema de caché para almacenar en caché las respuestas HTTP apropiadas y sus cargas útiles. Lo que se considera apropiado para la caché y cuando estas cachés se puede acceder se determina en realidad por la meta-información adicional en los encabezados HTTP (véase más adelante). Un servidor no puede almacenar en caché mientras actúa como un túnel HTTP (ver arriba). Estos cachés pueden existir en cualquier paso de la cadena, e incluso existen en el propio dispositivo cliente para almacenar en caché imágenes vistas comúnmente y otros recursos. Este propósito de un caché es reducir el tráfico de red, acelerar la entrega de contenido y equilibrar la carga de red para obtener nueva información.

Autenticación

La autenticación es básicamente proporcionar credenciales que demuestran que eres quien dices que eres, o que al menos tienes la autoridad para ver y operar en los recursos identificados por el URI. Existen varios esquemas de autenticación disponibles a través de HTTP, uno de ellos es la autenticación de acceso básico y otro es la autenticación de acceso de resumen. Ambos funcionan fuera de un sistema de desafío-respuesta, básicamente el servidor emite un reto (generalmente, ¿cuál es el nombre de usuario y contraseña) y una vez que el reto está satisfecho, sólo entonces es la solicitud procesada y atendida. Estos son dos esquemas de autenticación de ejemplo, pero HTTP también proporciona un marco general para el control de acceso y autenticación. Las personas a menudo también construyen sus propios medios y métodos de control de acceso usando claves públicas y privadas, de las cuales probablemente haya visto en muchos servicios HTTP alrededor de la web. El esquema desafío-respuesta es el marco general, y es extensible para que otros esquemas además de Basic y Digest puedan ser implementados.

La autenticación HTTP también tiene lo que se llama Realms de autenticación. Estos son un poco esotéricos, pero la idea es que un servidor puede implementar ámbitos separados para un URI que permite, básicamente, como se puede imaginar, diferentes pantallas de inicio de sesión para la misma URL dependiendo de la existencia de una cadena de valor de dominio. Este tipo de autenticación está algo fuera del alcance de este artículo más introductorio.

Conclusión

Eso es todo para la parte 1 del tutorial de protocolo HTTP. Hemos cubierto los conceptos básicos de HTTP y los tipos de información con los que trata. Sin embargo, no hemos cubierto la implementación específica de una solicitud o respuesta HTTP. En esas solicitudes y respuestas puede haber una gran cantidad de “metadatos” o datos asociados con un mensaje HTTP dado que pertenece a la longitud del contenido, tipo de contenido, almacenamiento en caché, enrutamiento, etc. Estos son llamados campos de datos de encabezado. Exploraremos el formato exacto de HTTP y estos campos de datos de cabecera en la siguiente parte. ¡Gracias!

Si usted aprecia mis tutoriales, por favor, ayúdenme a apoyar a través de mi Patreon.

Si un compromiso mensual no está en tu callejón, siempre puedes comprarme un poco de café.

photo credit: Kevin Baird 8493 UX / multimedia bookshelf via photopin (license)

Liked it? Take a second to support kadar on Patreon!

You may also like...

Deja un comentario

A %d blogueros les gusta esto: