ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Protocolo de transferencia de hipertexto wiki: info, historia y vídeos

videos internet

salud  Protocolo de transferencia de hipertexto 


El Protocolo de trasferencia de hipertexto (en inglés: Hypertext Transfer Protocol o bien HTTP) es el protocolo de comunicación que deja las trasferencias de información en la WWW. HTTP fue desarrollado por el WWW Consortium y la Internet Engineering Task Force, cooperación que acabó en mil novecientos noventa y nueve con la publicación de una serie de RFC, el más esencial de ellos es el RFC dos mil seiscientos dieciseis que detalla la versión once. HTTP define la sintaxis y la semántica que emplean los elementos de software de la arquitectura web (clientes del servicio, servidores, proxies) para comunicarse. HTTP es un protocolo sin estado, esto es, no guarda ninguna información sobre conexiones precedentes. El desarrollo de aplicaciones web precisa habitualmente sostener estado. Para ello se utilizan las cookies, que es información que un servidor puede guardar en el sistema cliente del servicio. Esto le deja a las aplicaciones web instaurar la noción de sesión, y asimismo deja rastrear usuarios puesto que las cookies pueden guardarse en el usuario por tiempo indeterminado.


Es un protocolo orientado a transacciones y prosigue el esquema solicitud-contestación entre un usuario y un servidor. El cliente del servicio (se le acostumbra a llamar "agente de usuario", en inglés usuario agent) efectúa una solicitud mandando un mensaje, con determinado formato al servidor. El servidor (se le acostumbra a llamar un servidor web) le manda un mensaje de contestación. Ejemplos de usuario son los navegadores web y las arañas web (asimismo conocidas por su término inglés, webcrawlers).


Los mensajes HTTP, son en texto plano lo que lo hace más inteligible y simple de depurar. Esto tiene el inconveniente de hacer los mensajes más largos.


Los mensajes tienen la próxima estructura:



  • Línea inicial (acaba con retorno de carro y un salto de línea) conPara las peticiones: la acción requerida por el servidor (procedimiento de solicitud) seguido de la URL del recurso y la versión HTTP que aguanta el usuario.Para respuestas: La versión del HTTP utilizado seguido del código de contestación (que señala que ha sucedido con la solicitud seguido de la URL del recurso) y de la oración asociada a dicho retorno.
  • Las cabeceras del mensaje que acaban con una línea en blanco. Son metadatos. Estas cabeceras le dan gran flexibilidad al protocolo.
  • Cuerpo del mensaje. Es opcional. Su presencia depende de la línea precedente del mensaje y del género de recurso al que hace referencia la URL. Típicamente tiene los datos que se intercambian cliente del servicio y servidor. Por servirnos de un ejemplo para una solicitud podría contener determinados datos que se quieren mandar al servidor a fin de que los procese. Para una contestación podría incluir los datos que el usuario ha pedido.

Métodos de petición

Un pedido HTTP utilizando telnet. El pedido (request), cabeceras de contestación (response headers) y el cuerpo de la contestación (response body) están destacados.

HTTP define una serie predefinida de métodos de solicitud (en ocasiones referido como "verbos") que pueden usarse. El protocolo tiene flexibilidad para ir agregando nuevos métodos y para de esta forma agregar nuevas funcionalidades. El número de métodos de solicitud se han ido incrementando conforme se avanzaban en las versiones. Cada procedimiento señala la acción que quiere que se realice sobre el recurso identificado. Lo que este recurso representa depende de la aplicación del servidor. Por servirnos de un ejemplo el recurso puede corresponderse con un fichero que radica en el servidor.


RFC dos mil seiscientos dieciseis. Solicita una contestación idéntica a la que correspondería a una solicitud GET, mas en la contestación no se devuelve el cuerpo. Esto es útil para poder recobrar los metadatos de los encabezados de contestación, sin transportar todo el contenido.


RFC dos mil seiscientos dieciseis. Solicita una representación del recurso concretado. Por seguridad no habría de ser utilizado por aplicaciones que ocasionen efectos en tanto que transmite información por medio de la URI añadiendo factores a la URL. La solicitud puede ser simple, o sea en una línea o bien compuesta de la forma que muestra el ejemplo. Ejemplo:

GET /images/logo.png HTTP/1.1 consigue un recurso llamado logotipo.png

Ejemplo con parámetros:

/index.php?page=main&lang=es

RFC dos mil seiscientos dieciseis. Manda los datos a fin de que sean procesados por el recurso identificado. Los datos se incluirán en el cuerpo de la solicitud. Esto puede resultar en la creación de un nuevo recurso o bien de las actualizaciones de los recursos existentes o bien las dos cosas.


RFC dos mil seiscientos dieciseis. Sube, carga o bien efectúa un upload de un recurso concretado (fichero), es el camino más eficaz para subir ficheros a un servidor, esto es pues en POST emplea un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el procedimiento PUT te deja redactar un fichero en una conexión socket establecida con el servidor. La desventaja del procedimiento PUT es que los servidores de alojamiento web compartido no lo tienen habilitado. Ejemplo:

PUT /path/filename.html HTTP/1.1

RFC dos mil seiscientos dieciseis. Borra el recurso concretado.


RFC dos mil seiscientos dieciseis. Este procedimiento pide al servidor que en la contestación meta todos y cada uno de los datos que reciba en el mensaje de solicitud. Se usa con fines de depuración y diagnóstico puesto que el usuario puede ver lo que llega al servidor y de este modo ver lo que agregan al mensaje los servidores intermedios


RFC dos mil seiscientos dieciseis. Devuelve los métodos HTTP que el servidor aguanta para un URL concreto. Esto puede ser usado para revisar la funcionalidad de un servidor web a través de solicitud en vez de un recurso concreto.


RFC dos mil seiscientos dieciseis. Se emplea para saber si se tiene acceso a un host, no necesariamente la solicitud llega al servidor, este procedimiento se emplea primordialmente para saber si un proxy nos da acceso a un host bajo condiciones singulares, como por poner un ejemplo "corrientes" de datos bidireccionales cifradas (como lo requiere SSL).


Su función es exactamente la misma que PUT, Se emplea para actualizar, mas la diferencia radica en que aquí puedes seleccionar parcialmente una o bien múltiples partes.


/P>

/P>

RFC 2518


RFC 2323


RFC 2518


RFC 2518


RFC 2518


RFC 2518


RFC 2518


RFC 3253


RFC 3253


RFC 3253


Códigos de respuesta

Códigos de estado HTTP

El código de contestación o bien retorno es un número que señala que ha ocurrido con la solicitud.El resto del contenido de la contestación va a depender del valor de este código. El sistema es flexible y en verdad la lista de códigos ha ido incrementando para de esta forma amoldarse a los cambios y también identificar nuevas situaciones. Cada código tiene un significado específico. No obstante el número de los códigos están escogidos de tal modo que conforme si pertenece a una centena o bien otra se pueda identificar el género de contestación que ha dado el servidor:



  • Códigos con formato 1xx: Contestaciones informativas. Señala que la solicitud ha sido recibida y se está procesando.
  • Códigos con formato 2xx: Contestaciones adecuadas. Señala que la solicitud ha sido procesada adecuadamente.
  • Códigos con formato 3xx: Contestaciones de redirección. Señala que el usuario precisa efectuar más acciones finalmente la solicitud.
  • Códigos con formato 4xx: Fallos ocasionados por el cliente del servicio. Señala que ha habido un fallo en el procesado de la solicitud a raíz de que el cliente del servicio ha hecho algo mal.
  • Códigos con formato 5xx: Fallos ocasionados por el servidor. Señala que ha habido un fallo en el procesado de la solicitud a raíz de un fallo en el servidor.
Cabeceras HTTP

Son los metadatos que se mandan en las solicitudes o bien contestación HTTP para otorgar información esencial sobre la transacción en curso. Cada cabecera es detallada por un nombre de cabecera seguido por 2 puntos, un espacio en blanco y el valor de dicha cabecera seguida por un retorno de carro seguido por un salto de línea. Se utiliza una línea en blanco para señalar el final de las cabeceras. Si no hay cabeceras la línea en blanco debe continuar.


Las cabeceras le dan gran flexibilidad al protocolo dejando agregar nuevas funcionalidades sin mudar la base. De ahí que conforme han ido sucediendo las versiones de HTTP se han ido agregando cada vez más y más cabeceras toleradas.


Las cabeceras pueden tener metadatos que deben ser procesados por el usuario (ej. como contestación a solicitud se puede apuntar el tipo del contenido que contiene), por el servidor (ej. géneros de representaciones admisibles por el usuario del contenido que solicita) o bien por los intercesores (ej. como administrar el cacheo por la parte de los proxys)


Dependiendo del género de mensaje en el que puede ir una cabecera las podemos clasificar en cabeceras de solicitud, cabeceras de contestación y cabeceras que pueden ir tanto en un solicitud como en una contestación.


Podemos clasificar las cabeceras conforme su función. Por ejemplo:



  • Cabeceras que señalan las capacidades admitidas por el que manda el mensaje: Accept (señala el MIME admitido), Accept-Charset (señala el código de caracteres admitido), Accept-Encoding (señala el procedimiento de compresión admitido), Accept-Language (señala el idioma admitido), Usuario-Agent (para describir al usuario), Server (señala el género de servidor), Allow (métodos tolerados para el recurso)
  • Cabeceras que describen el contenido: Content-Type (señala el MIME del contenido), Content-Length (longitud del mensaje), Content-Range, Content-Encoding, Content-Language, Content-Location.
  • Cabeceras que hacen referencias a URIs: Location (señala donde está el contenido), Referer (Señala el origen de la solicitud).
  • Cabeceras que dejan ahorrar transmisiones: Date (data de creación), If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range, Expires, Last-Modified, Cache-Control, Vía, Pragma, Etag, Age, Retry-After.
  • Cabeceras para control de cookies: Set-Cookie, Cookie
  • Cabeceras para autentificación: Authorization, WW-Authenticate
  • Cabeceras para describir la comunicación: Host (señala máquina destino del mensaje), Connection (señala como establecer la conexión)
  • Otras: Range (para descargar solo unas partes del recurso), Max-Forward (límite de cabeceras añadidas en TRACE).

Ejemplo de diálogo HTTP


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



  1. Se abre una conexión en el puerto ochenta del host www.example.com .El puerto ochenta es el puerto predefinido para HTTP. Si se quisiese emplear el puerto XXXX habría que codificarlo en la URL de la manera http://www.example.com:XXXX/index.html
  2. Se manda un mensaje en el estilo siguiente:
GET /index.html HTTP/1.1 Host: www.example.com Referer: www.google.com Usuario-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Connection: keep-alive /PRE>

La contestación del servidor está formada por encabezados seguidos del recurso pedido, en el caso de una página web:

HTTP/1.1 doscientos OKDate: Fri, treinta y uno Dec dos mil tres 23:59:59 GMTContent-Type: text/htmlContent-Length: 1221<html lang="eo"><head><meta charset="utf-ocho"><title>Título del sitio</title></head><body><h1>Página primordial de tuHost</h1>(Contenido) . . .</body></html>


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 

Está aquí: Inicio > [ INTERNET ] > ıllı Protocolo de transferencia de hipertexto wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas