HTTP

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 
 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
         ┌───────┴───────┐ ┌────┴────────┐ ┌┴┐
  
  └─┬─┘ └───────────┬────────────────────────┘└─┬─────────────┘└────────┬──────────────────┘└┬─┘
  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 
[miniatura|[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, 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.

## 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.

#### Métodos de solicitude 
miniatura|dereita|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). 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. Microsoft IIS admite un método patentado "TRACK", que se comporta de maneira similar, e que tamén se recomenda desactivar.

#### 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 
```http
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
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

  
    Unha páxina de exemplo
  
  
    Ola Mundo, isto é un documento HTML moi simple
  

```

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.

## Notas 
## Véxase tamén 
### Ligazóns externas 
*  A detailed technical history of HTTP.
*  Design Issues by Berners-Lee when he was designing the protocol.
*  list of other classic documents recounting the early protocol history
* HTTP 0.9 – As Implemented in 1991
* HTTP/2 Website Online Tester