HTTP

HTTP
Tipo	protocolo de rede
Data de fundación	1989
Na rede
https://httpwg.org/specs/
[ editar datos en Wikidata ]

O Protocolo de Transferencia de Hipertexto (HTTP) é un protocolo de aplicación para sistemas de información de hipermedia distribuídos, colaborativos. HTTP é a base da comunicación de datos para a World Wide Web, onde os documentos de hipertexto inclúen hiperligazóns a outros recursos aos que o usuario pode acceder facilmente, por exemplo, facendo clic co rato ou tocando a pantalla nun navegador web. HTTP foi desenvolto para facilitar o hipertexto e a World Wide Web.

O desenvolvemento de HTTP foi iniciado por Tim Berners-Lee no CERN en 1989. O desenvolvemento dos estándares HTTP foi un esforzo coordinado polo Grupo de traballo de enxeñería de Internet (IETF) e a World Wide Web Consortium (W3C). Os esforzos culminaron na publicación dunha serie de solicitudes de comentarios (RFC). A primeira definición de HTTP/1.1, a versión de HTTP aínda en uso común, ocorreu no RFC 2068 en 1997. Esta versión foi desaprobada polo RFC 2616 en 1999, que logo foi substituída pola familia RFC 7230 en 2014.

Unha versión posterior, HTTP/2, estandarizouse en 2015. HTTP/3 é o sucesor proposto (Internet Draft) que se basea en HTTP/2 e agora é compatible cos principais servidores web e navegadores a través da Transport Layer Security (TLS) usando unha extensión da Application-Layer Protocol Negotiation (ALPN) onde se require TLS 1.2 ou máis recente.

Resumo técnico

{{HTTP}} funciona como un protocolo de solicitude-resposta no modelo computacional cliente-servidor. Unha navegador web, por exemplo, pode ser o cliente e unha aplicación que se executa nunha computadora que aloxa un sitio web pode ser o servidor. O cliente envía unha mensaxe de solicitude HTTP ao servidor. O servidor, que proporciona recursos como arquivos" HTML" e outro contido, ou realiza outras funcións en nome do cliente, devolve unha mensaxe de resposta ao cliente. A resposta contén información de estado de finalización sobre a solicitude e tamén pode conter contido solicitado no corpo da súa mensaxe.

Unha navegador web é un exemplo dun axente de usuario (UA). Outros tipos de axente de usuario inclúen o software de indexación utilizado polos provedores de procura (rastreadores web), buscadores de voz, aplicacións móbiles e outro software que accede, consome ou mostra contido web.

HTTP está deseñado para permitir que os elementos intermedios da rede melloren ou habiliten as comunicacións entre clientes e servidores. Os sitios web de alto tráfico a miúdo benefícianse dos servidores de caché web que ofrecen contido en nome dos servidores ascendentes para mellorar o tempo de resposta. Os navegadores web almacenan en caché os recursos web aos que accedeu anteriormente e reutilízanos, cando é posíbel, para reducir o tráfico de rede. Os servidores proxy HTTP nos límites da rede privada poden facilitar a comunicación para os clientes sen unha dirección enrutábel globalmente, mediante a retransmisión de mensaxes con servidores externos.

HTTP é un protocolo de capa de aplicación deseñado dentro do marco da suite de protocolos de Internet. A súa definición supón un protocolo de capa de transporte subxacente e fiábel, e o Protocolo de Control de Transmisión (TCP) úsase comunmente. Con todo, HTTP pode adaptarse para utilizar protocolos non fiabeis como o Protocolo de datagramas de usuario (UDP), por exemplo en HTTPU e o Protocolo simple de detección de servizos (SSDP).

Os recursos* HTTP son identificados e situados na rede por Localizadores Uniformes de Recursos (URL), utilizando os esquemas http e https dos Identificadores Uniformes de Recursos* (URI). Por exemplo, incluíndo todas as compoñentes opcionais:

             userinfo          host        port
         ┌───────┴───────┐ ┌────┴────────┐ ┌┴┐
  http://john.doe:password@www.example.com:123/forum/questions/?tag=networking&order=newest#top
  └─┬─┘ └───────────┬────────────────────────┘└─┬─────────────┘└────────┬──────────────────┘└┬─┘
  scheme         authority                      path                  query               fragment

As URI codifícanse como hipervínculos nos documentos HTML, para formar documentos de hipertexto interconectados.

HTTP/1.1 é unha revisión do HTTP orixinal (HTTP/1.0). En HTTP/1.0, realízase unha conexión independente ao mesmo servidor para cada solicitude de recurso. HTTP/1.1 pode reutilizar unha conexión varias veces para descargar imaxes, scripts, follas de estilo, etc. despois de que se entregou a páxina. Polo tanto, as comunicacións HTTP/1.1 experimentan menos latencia xa que o estabelecemento de conexións TCP presenta unha sobrecarga considerábel.

Historia

Tim Berners-Lee

O termo hipertexto foi acuñado por Ted Nelson en 1965 no Proxecto Xanadu, que á súa vez se inspirou na visión de Vannevar Bush na década de 1930 do sistema "memex" de recuperación de información baseado en microfilm, descrito no seu ensaio de 1945 "Como podemos pensar". Tim Berners-Lee e o seu equipo no CERN son acreditados coa invención do HTTP orixinal, xunto con HTML e a tecnoloxía asociada para un servidor web e un navegador web baseado en texto. Berners-Lee propuxo por primeira vez o proxecto "WorldWideWeb" en 1989, agora coñecido como World Wide Web. A primeira versión do protocolo tiña só un método, a saber, GET, que solicitaría unha páxina dun servidor. A resposta do servidor sempre foi unha páxina HTML.

A primeira versión documentada de HTTP foi HTTP V0.9 (1991). Dave Raggett dirixiu o Grupo de Traballo HTTP (HTTP WG) en 1995 e quería expandir o protocolo con operacións estendidas, negociación estendida, metainformación máis rica, vinculado cun protocolo de seguridade que se volveu máis eficiente ao agregar métodos adicionais e campos de encabezado. RFC 1945 presentou e recoñeceu oficialmente HTTP V1.0 no 1996.

O HTTP WG planeaba publicar novos estándares en decembro de 1995 e o soporte para o estándar HTTP/1.1 baseado no RFC 2068 en desenvolvemento (chamado HTTP-NG) foi rapidamente adoptado polos principais desenvolvedores de navegadores a principios de 1996. Por marzo dese ano, admitiuse o estándar HTTP/1.1 en Arena, Netscape 2.0, Netscape Navigator Gold 2.01, Mosaic 2.7, Lynx 2.5, e no Internet Explorer 2.0. A adopción por parte do usuario final dos novos navegadores foi rápida. En marzo de 1996, unha empresa de aloxamento web informou que máis do 40% dos navegadores en uso en Internet eran compatibles con HTTP 1.1. Esa mesma empresa de aloxamento web informou que, en xuño de 1996, o 65% de todos os navegadores que accedían aos seus servidores eran HTTP/1.1. O estándar HTTP/1.1, tal como defínese no RFC 2068, lanzouse oficialmente en xaneiro de 1997. As melloras e actualizacións ao estándar HTTP/1.1 publicáronse baixo o RFC 2616 en xuño de 1999.

En 2007, o Grupo de Traballo HTTPbis formouse, en parte, para revisar e aclarar a especificación HTTP/1.1. En xuño de 2014, o WG publicou unha especificación de seis partes obsoleta no RFC 2616:

• RFC 7230, HTTP/1.1: Message Syntax and Routing
• RFC 7231, HTTP/1.1: Semantics and Content
• RFC 7232, HTTP/1.1: Conditional Requests
• RFC 7233, HTTP/1.1: Range Requests
• RFC 7234, HTTP/1.1: Caching
• RFC 7235, HTTP/1.1: Authentication

HTTP/2 foi publicado no RFC 7540 en maio do 2015.

Ano	Versión HTTP
1991	0.9
1996	1.0
1997	1.1
2015	2.0
2018	3.0

Sesión HTTP

Unha sesión HTTP é unha secuencia de transaccións de solicitude-resposta da rede. Un cliente HTTP inicia unha solicitude estabelecendo unha conexión de Protocolo de Control de Transmisión (TCP) a un porto particular nun servidor (xeralmente o porto 80, ocasionalmente o porto 8080; consulte a Lista de números de portos TCP e UDP). Un servidor HTTP que escoita nese porto espera a mensaxe de solicitude dun cliente. Ao recibir a solicitude, o servidor devolve unha liña de estado, como "HTTP/1.1 200 OK", e unha mensaxe propia. O corpo desta mensaxe adoita ser o recurso solicitado, aínda que tamén se pode devolver unha mensaxe de erro ou outra información.

Conexións persistentes

En HTTP/0.9 e 1.0, a conexión péchase despois dun só par de solicitude/esposta. En HTTP/1.1 introduciuse un mecanismo para manter vivo, no que unha conexión podería reutilizarse para máis dunha solicitude. Estas conexións persistentes reducen a latencia da solicitude perceptíbelmente, porque o cliente non necesita volver negociar a conexión TCP 3-Way-Handshake despois de que se enviou a primeira solicitude. Outro efecto secundario positivo é que, en xeral, a conexión vólvese máis rápida co tempo debido ao mecanismo de inicio lento de TCP.

A versión 1.1 do protocolo tamén realizou melloras na optimización do ancho de banda a HTTP/1.0. Por exemplo, HTTP/1.1 introduciu a codificación de transferencia fragmentada para permitir que o contido das conexións persistentes transmítase no canto de almacenarse no búfer. A canalización de HTTP reduce aínda máis o tempo de demora, o que permite aos clientes enviar múltiples solicitudes antes de esperar cada resposta. Outra adición ao protocolo foi o servizo de bytes, onde un servidor transmite só a parte dun recurso solicitado explicitamente por un cliente.

Estado da sesión HTTP

HTTP é un protocolo sen estado. Un protocolo sen estado non require que o servidor HTTP reteña información ou estado de cada usuario durante a duración de múltiples solicitudes. Con todo, algunhas aplicacións web implementan estados ou sesións ao lado do servidor utilizando, por exemplo, cookies HTTP ou variabeis ocultas dentro de formularios web.

Autenticación HTTP

HTTP proporciona múltiples esquemas de autenticación, como a autenticación de acceso básico e a autenticación de acceso de resumo, que funcionan a través dun mecanismo de resposta de desafío mediante o cal o servidor identifica e emite un desafío antes de servir o contido solicitado.

HTTP proporciona un marco xeral para o control de acceso e a autenticación, a través dun conxunto extensible de esquemas de autenticación de desafío-resposta, que pode ser utilizado por un servidor para desafiar unha solicitude do cliente e por un cliente para proporcionar información de autenticación.

Dominios de autenticación

A especificación de autenticación HTTP tamén proporciona unha construción arbitraria, específica da posta en funcionamento, para dividir aínda máis os recursos comúns a unha URI raíz dado. A cadea de valor do dominio, se está presente, combínase coa URI raíz canónica para formar a compoñente de espazo de protección do desafío. En efecto, isto permite que o servidor defina ámbitos de autenticación separados nunha URI raíz.

Formato da mensaxe

O cliente envía solicitudes ao servidor e o servidor envía respostas.

Mensaxe de solicitude

A mensaxe de solicitude consiste no seguinte:

• Unha liña de solicitude (por exemplo, GET /images/logo.png HTTP/1.1, que solicita un recurso chamado /images/logo.png do servidor).
• Campos de encabezado de solicitude (por exemplo, Accept-Language: gal).
• Unha liña baleira.
• Un corpo de mensaxe opcional.

A liña de solicitude e outros campos de encabezado deben terminar con <CR><LF> (é dicir, un carácter de retorno de carro seguido dun carácter de avance de liña). A liña baleira debe constar de só <CR><LF> e non doutros espazos en branco. No protocolo HTTP/1.1, todos os campos de encabezado, excepto o Host, son opcionais.

Os servidores aceptan unha liña de solicitude que contén só o nome da ruta para manter a compatibilidade cos clientes HTTP antes da especificación HTTP/1.0 no RFC 1945.

Métodos de solicitude

Unha solicitude HTTP 1.1 realizada utilizando telnet. A mensaxe de solicitude, a sección do encabezado de resposta e o corpo da resposta están resaltados.

HTTP define métodos (ás veces denominados verbos, pero en ningures da especificación menciona verbo, nin OPTIONS ou HEAD é un verbo) para indicar a acción que se desexa realizar no recurso identificado. O que representa este recurso, xa sexa que os datos preexistentes ou os datos que se xeran dinámicamente, depende da posta en funcionamento do servidor. A miúdo, o recurso corresponde a un arquivo ou a saída dun executábel que reside no servidor. A especificación de HTTP/1.0 definiu os métodos GET, HEAD e POST, e a especificación de HTTP/1.1 agregou cinco novos métodos: OPTIONS, PUT, DELETE, TRACE e CONNECT. Ao especificarse nestes documentos, a súa semántica é ben coñecida e pódese confiar nela. Calquera cliente pode usar calquera método e o servidor pode configurarse para admitir calquera combinación de métodos. Se un método é descoñecido para un intermediario, tratarase como un método inseguro e non idempotente. Non hai límite no número de métodos que se poden definir e isto permite que se especifiquen métodos futuros sen romper a infraestrutura existente. Por exemplo, WebDAV definiu 7 métodos novos e RFC 5789 especificou o método PATCH.

Os nomes dos métodos distinguen entre maiúsculas e minúsculas. Isto contrasta cos nomes de campo do encabezado HTTP que distinguen entre maiúsculas e minúsculas.

GET

O método GET solicita unha representación do recurso especificado. As solicitudes que utilizan GET só deben recuperar datos e non deben ter ningún outro efecto. (Isto tamén se aplica a algúns outros métodos HTTP). O W3C publicou principios de orientación sobre esta distinción, dicindo que "o deseño da aplicación web debe estar informado polos principios anteriores, pero tamén polas limitacións relevantes". Vexa os métodos seguros a continuación.

HEAD

O método HEAD solicita unha resposta idéntica á dunha solicitude GET, pero sen o corpo de resposta. Isto é útil para recuperar metainformación escrita en encabezados de resposta, sen ter que transportar todo o contido.

POST

O método POST solicita que o servidor acepte a entidade incluída na solicitude como un novo subordinado do recurso web identificado pola URI. Os datos POSTeados poden ser, por exemplo, unha anotación para os recursos existentes; unha mensaxe para un taboleiro de anuncios, un grupo de noticias, unha lista de correo ou un fío de comentarios; un bloque de datos que é o resultado de enviar un formulario web a un proceso de manexo de datos; ou un elemento para agregar a unha base de datos.

PUT

O método PUT solicita que a entidade adxunta almacénese baixo a URI provista. Se a URI refírese a un recurso xa existente, modifícase; Se a URI non apunta a un recurso existente, entón o servidor pode crear o recurso con esa URI.

DELETE

O método DELETE elimina o recurso especificado.

TRACE

O método TRACE faise eco da solicitude recibida para que un cliente poida ver que cambios ou adicións (no seu caso) realizaron os servidores intermedios.

OPTIONS

O método OPTIONS devolve os métodos HTTP que o servidor admite para a URL especificada. Isto pódese usar para verificar a funcionalidade dun servidor web solicitando '*' en lugar dun recurso específico.

CONNECT

O método CONNECT converte a conexión de solicitude a un túnel TCP/IP transparente, xeralmente para facilitar a comunicación cifrada con SSL (HTTPS) a través dun proxy HTTP sen cifrar. Ver o método HTTP CONNECT.

PATCH

O método PATCH aplica modificacións parciais a un recurso.

Todos os servidores HTTP de propósito xeral deben poñer en funcionamento polo menos os métodos GET e HEAD, e todos os demais métodos considéranse opcionais pola especificación.

Métodos seguros

Algúns dos métodos (por exemplo, GET, HEAD, OPTIONS e TRACE) están, por convención, definidos como seguros, o que significa que están destinados só para a recuperación de información e non deben cambiar o estado do servidor. Noutras palabras, non deberían ter efectos secundarios, máis aló de efectos relativamente inofensivos, como o rexistro, o almacenamento en caché web, a publicación de anuncios publicitarios ou o incremento dun contador web. Facer solicitudes GET arbitrarias sen ter en conta o contexto do estado da aplicación, polo tanto, debe considerarse seguro. Con todo, isto non é obrigatorio pola norma, e ​​recoñécese explicitamente que non se pode garantir.

Pola contra, os métodos como POST, PUT, DELETE e PATCH están deseñados para accións que poden causar efectos secundarios no servidor ou efectos secundarios externos, como transaccións financeiras ou transmisión de correo electrónico. Polo tanto, tales métodos non adoitan ser utilizados por robots web ou rastreadores web conformes; algúns que non se axustan tenden a realizar solicitudes sen ter en conta o contexto ou as consecuencias.

A pesar da seguridade prescrita das solicitudes GET, na práctica o seu manexo por parte do servidor non está tecnicamente limitado de ningunha maneira. Polo tanto, a programación descoidada ou deliberada pode causar cambios non triviais no servidor. Isto non se recomenda, xa que pode causar problemas para o almacenamento en caché web, os motores de procura e outros axentes automatizados, que poden facer cambios non desexados no servidor. Por exemplo, un sitio web pode permitir a eliminación dun recurso a través dunha URL como http://example.com/article/1234/delete, que, se se obtén de forma arbitraria, incluso utilizando GET, simplemente eliminaría o artigo.

Un exemplo disto ocorreu na práctica foi durante a breve vida de Google Web Accelerator Beta, na que se atopaban as URLs arbitrarias na páxina que un usuario estaba a ver, o que provocaba que os rexistros se alterasen ou eliminasen automaticamente en masa. A versión Beta suspendeuse só unhas semanas despois do seu primeiro lanzamento, logo de críticas xeneralizadas.

Métodos idempotentes e aplicacións web

Os métodos PUT e DELETE defínense como idempotentes, o que significa que varias solicitudes idénticas deben ter o mesmo efecto que unha soa solicitude (teña en conta que a identificación de instancias refírese ao estado do sistema despois de que a solicitude completouse, polo tanto, a acción que realiza o servidor (por exemplo, eliminar un rexistro) ou o código de resposta que devolve pode ser diferente nas solicitudes posteriores, o estado do sistema será o mesmo cada vez). Os métodos GET, HEAD, OPTIONS e TRACE, que se prescriben como seguros, tamén deben ser idempotentes, xa que HTTP é un protocolo sen estado.

En contraste, o método POST non é necesariamente idempotente e, polo tanto, enviar unha solicitude POST idéntica varias veces pode afectar aínda máis ao estado ou causar outros efectos secundarios (como transaccións financeiras). Nalgúns casos, isto pode ser desexábel, pero noutros casos pode deberse a un accidente, como cando un usuario non se dá conta de que a súa acción resultará no envío doutra solicitude, ou non recibiu unha resposta adecuada de que a súa primeira solicitude foi exitosa. Aínda que os navegadores web poden mostrar cadros de diálogo de alerta para advertir aos usuarios nalgúns casos nos que a recarga dunha páxina pode volver enviar unha solicitude POST, xeralmente depende da aplicación web manexar os casos en que unha solicitude POST non debe enviarse máis dunha vez.

Teña en conta que o protocolo ou o servidor web non impoñen un método idempotente. É perfectamente posible escribir unha aplicación web na que (por exemplo) unha inserción de base de datos ou outra acción non idempotente é activada por un GET ou outra solicitude. Ignorar esta recomendación, con todo, pode ter consecuencias indesexabeis, se un axente de usuario asume que repetir a mesma solicitude é seguro cando non o é.

Seguridade

O método TRACE pódese usar como parte dunha clase de ataques coñecidos como Cross-site tracing; por esa razón, o consello de seguridade común é que se deshabilite na configuración do servidor. Microsoft IIS admite un método patentado "TRACK", que se comporta de maneira similar, e que tamén se recomenda desactivar.

Táboa de resumo

Método HTTP	RFC	Solicitude ten Corpo	Resposta ten Corpo	Seguro	Idempotente	Cacheábel
GET	RFC 7231	Opcional	Si	Si	Si	Si
HEAD	RFC 7231	Opcional	Non	Si	Si	Si
POST	RFC 7231	Si	Si	Non	Non	Si
PUT	RFC 7231	Si	Si	Non	Si	Non
DELETE	RFC 7231	Opcional	Si	Non	Si	Non
CONNECT	RFC 7231	Opcional	Si	Non	Non	Non
OPTIONS	RFC 7231	Opcional	Si	Si	Si	Non
TRACE	RFC 7231	Non	Si	Si	Si	Non
PATCH	RFC 7231	Si	Si	Non	Non	Non

Mensaxe de resposta

A mensaxe de resposta consiste no seguinte:

• Unha liña de estado que inclúe o código de estado e a mensaxe da razón (por exemplo, HTTP/1.1 200 OK, que indica que a solicitude do cliente foi exitosa).
• Campos de encabezado de resposta (por exemplo, Content-Type: text/html).
• Unha liña baleira.
• Un corpo de menxase opcional.

A liña de estado e outros campos de encabezado deben terminar con <CR><LF>. A liña baleira debe constar de só <CR><LF> e non doutros espazos en branco. Este requisito estrito para <CR><LF> reláxase un pouco dentro dos corpos das mensaxes para un uso consistente doutros saltos de liña do sistema como <CR> ou <LF> só.

Códigos de estado

En HTTP/1.0 e desde entón, a primeira liña da resposta HTTP chámase a liña de estado e inclúe un código de estado numérico (como "404") e unha frase de motivo textual (como "Not Found"). A forma en que o axente de usuario manexa a resposta depende principalmente do código e, en segundo lugar, dos outros campos de encabezado de resposta. Pódense usar códigos de estado personalizados, xa que se o axente de usuario atopa un código que non recoñece, pode usar o primeiro díxito do código para determinar a clase xeral da resposta.

As frases de motivo estándar son só recomendacións e pódense substituír por "equivalentes locais" a discreción do desenvolvedor web. Se o código de estado indica un problema, o axente de usuario pode mostrar a reason phrase ao usuario para proporcionar máis información sobre a natureza do problema. A norma tamén permite que o axente de usuario tente interpretar a reason phrase, aínda que isto podería ser imprudente, xa que a norma especifica explicitamente que os códigos de estado son lexibeis por máquina e as reason phrases son lexibeis por humáns. O código de estado HTTP divídese principalmente en cinco grupos para unha mellor explicación da solicitude e as respostas entre o cliente e o servidor como se chama:

• Informativo 1XX
• Exitoso 2XX
• Redirección 3XX
• Erro no cliente 4XX
• Erro no servidor 5XX

Conexións encriptadas

A forma máis popular de establecer unha conexión HTTP encriptada é HTTPS. Tamén existen outros dous métodos para establecer unha conexión HTTP cifrada: o Secure Hypertext Transfer Protocol e o uso do encabezado HTTP/1.1 Upgrade para especificar unha actualización a TLS. Con todo, o soporte do navegador para estes dous é case inexistente.

Sesión de exemplo

A continuación móstrase unha conversación de mostra entre un cliente HTTP e un servidor HTTP que se executa en www.example.com, porto 80.

Solicitude do cliente

GET / HTTP/1.1
Host: www.example.com

Unha solicitude de cliente (que consta neste caso da liña de solicitude e só un campo de encabezado) vai seguida dunha liña en branco, de modo que a solicitude finaliza cunha nova liña nova, cada unha en forma dun retorno de carro seguido dun salto de liña. O campo "Host" distingue entre varios nomes DNS que comparten un único enderezo IP, o que permite o aloxamento virtual baseado no nome. Aínda que é opcional en HTTP/1.0, é obrigatorio en HTTP/1.1. ("/" significa /index.html se hai un).

Resposta do servidor

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>Unha páxina de exemplo</title>
  </head>
  <body>
    <p>Ola Mundo, isto é un documento HTML moi simple</p>
  </body>
</html>

O campo de encabezado ETag (etiqueta de entidade) utilízase para determinar se unha versión en caché do recurso solicitado é idéntica á versión actual do recurso no servidor. Content-Type especifica o tipo de medio de Internet dos datos transmitidos pola mensaxe HTTP, mentres que Content-Length indica a súa lonxitude en bytes. O servidor web HTTP/1.1 publica a súa capacidade para responder a solicitudes de certos rangos de bytes do documento estabelecendo o campo Accept-Ranges: bytes. Isto é útil, se o cliente necesita ter só certas porcións dun recurso enviado polo servidor, que se denomina servizo de bytes. Cando se envía Connection: close, significa que o servidor web pechará a conexión TCP inmediatamente despois da transferencia desta resposta.

A maioría das liñas de encabezado son opcionais. Cando falta o campo Content-Length, a lonxitude determínase doutras maneiras. A codificación de transferencia fragmentada utiliza un tamaño de fragmento de 0 para marcar o final do contido. A codificación de identidade sen Content-Length le o contido ata que se pecha o socket.

Pódese utilizar un Content-Encoding como gzip para comprimir os datos transmitidos.

Protocolos similares

O protocolo Gopher é un protocolo de entrega de contido que foi desprazado por HTTP a principios dos anos noventa. O protocolo SPDY é unha alternativa ao HTTP desenvolto en Google, e é substituído polo novo protocolo HTTP, HTTP/2.

Véxase tamén

Ligazóns externas

• "Change History for HTTP". W3.org. Consultado o 2010-08-01.  A detailed technical history of HTTP.
• "Design Issues for HTTP". W3.org. Consultado o 2010-08-01.  Design Issues by Berners-Lee when he was designing the protocol.
• "Classic HTTP Documents". W3.org. 1998-05-14. Consultado o 2010-08-01.  list of other classic documents recounting the early protocol history
• HTTP 0.9 – As Implemented in 1991
• HTTP/2 Website Online Tester Arquivado 30 de setembro de 2020 en Wayback Machine.

---

Este artigo sobre informática é, polo de agora, só un bosquexo. Traballa nel para axudar a contribuír a que a Galipedia mellore e medre.  Existen igualmente outros artigos relacionados con este tema nos que tamén podes contribuír.

---