HTTP

**HTTP** edo **H**yper**T**ext **T**ransfer **P**rotocol (Hipertestuaren transferentziarako protokoloa) World Wide Webean datuak elkartrukatzeko erabiltzen den protokoloa da. Hasierako helburua HTML orrialdeak argitaratu eta jasotzeko bidea ahalbidetzea zen.

HTTP Tim Berners-Lee hasi zen garatzen 1989an, CERNen, eta dokumentu sinple batean laburbildu zuen, zeinetan bezero baten eta zerbitzari baten portaera deskribatzen zuen, 0,9 izeneko lehen HTTP bertsioa erabiliz . Bertsio hori geroago garatu zen, azkenean 1.0 publiko bihurtuz.

Urte batzuk geroago HTTP (RFC) Request For Comments egiten hasi zen, Internet Engineering Task Force-k (IETF) eta World Wide Web Consortium-ak (W3C) koordinatutako ahaleginean, ondoren lana IETFra eramanez.

HTTP/1 osorik amaitu eta dokumentatu zen (1.0 bertsio gisa) 1996an.1997an eboluzionatu egin zuen (1.1 bertsio gisa), eta gero haren zehaztapenak 1999, 2014 eta 2022an eguneratu ziren.

HTTPS izeneko aldaera segurua webguneen %85ek baino gehiagok erabiltzen dute. HTTP/2, 2015. urtean argitaratua, HTTPren semantikaren adierazpen eraginkorragoa eskaintzen du igorpenean. 2023ko apirilera arte, webguneen %39k erabiltzen dute, eta ia web nabigatzaile guztiek (erabiltzaileen %97k baino gehiagok) babesten dute. Garraio Geruzako Segurtasunari (TLS) buruzko web-zerbitzari nagusiek ere onartzen dute, Aplikazioa Geruza-protokoloaren negoziazio-luzapen bat erabiliz (ALPN), non TLS 1.2 edo handiagoa behar den.

HTTP/3, HTTP/2ren ondorengoa, 2022an argitaratu zen. Gaur egun, webguneen %26 baino gehiagotan erabiltzen da, eta bateragarria da web nabigatzaile gehienekin, hau da, bateragarria da (partzialki behintzat) web nabigatzaileen %94rekin. HTTP/3k TCPren ordez QUIC erabiltzen du azpiko garraio-protokolorako. HTTP/2k bezala, ez ditu zaharkituta uzten protokoloaren aurreko bertsio nagusiak. HTTP/3rako euskarria Cloudflare-ri eta Google Chromeri gehitu zitzaien lehenik, eta Firefoxen ere gaituta dago. HTTP/3k latentzia baxuagoa du mundu errealeko webguneetarako, zerbitzarian gaituta badago, HTTP/2rekin baino azkarrago kargatzen du, baita HTTP/1.1 baino azkarrago ere, kasu batzuetan HTTP/1.1 baino 3 aldiz azkarragoa (eskuarki soilik gaitzen dena).
## Historia 
Hipertestu terminoa Ted Nelsonek sortu zuen 1965ean Xanadu Proiektuan, eta, aldi berean, Vannevar Bushek 1930eko hamarkadan informazioa kudeatzeko eta berreskuratzeko "memex" sistemari buruz emandako ikuspegian inspiratu zen, "As We May Think" 1945eko saiakeran deskribatutako mikrofilmetan oinarrituta. Tim Berners-Leeri eta CERNeko bere taldeari HTTP originala asmatzea egozten zaie, HTMLrekin eta web-zerbitzari baterako eta web nabigatzaile izeneko erabiltzaile-interfaze bezero baterako lotutako teknologiarekin batera. Berners-Leek HTTP diseinatu zuen bere beste ideia hartzen laguntzeko: "WorldWideWeb" proiektua, lehen aldiz 1989an proposatua, orain World Wide Web gisa ezagutzen dena.

Lehen web-zerbitzaria 1990ean jarri zen martxan. Erabilitako protokoloak metodo bakarra zuen, GET izenekoa, zerbitzari bati orri bat eskatuko ziona. Zerbitzariaren erantzuna beti HTML orrialde bat zen.

### HTTP mugarrien bertsioen laburpena 
HTTPk protokoloaren bertsio ugari izan ditu, eta horietako asko aurrekoekin bateragarriak dira. RFC 2145ak HTTP bertsio zenbakien erabilera deskribatzen du. Bezeroak eskaeraren hasieran zerbitzariari esaten dio zer bertsio erabiltzen duen, eta zerbitzariak bertsio bera edo aurrekoa erabiltzen du bere erantzunean.

ImageSize = width:610 height:60 
PlotArea = width:600 height:30 left:6 bottom:20 
Period = from:1990 till:2022 
TimeAxis = orientation:horizontal 
ScaleMajor = unit:year increment:5 start:1991 
ScaleMinor = unit:year increment:2 start:2018 
PlotData=
  bar:Líderes color:green width:25 mark:(line,white) align:center fontsize:S
  from:start till:1996  text:HTTP 0.9
  from:1996  till:1999  text:HTTP 1.0
  from:1999  till:2015  text:HTTP 1.1
  from:2015  till:2018  text:HTTP 2.0
  from:2018  till:2022  text:HTTP 3.0

;HTTP/0.9 (1991ean argitaratua)
:1991n, HTTPren lehen bertsio ofizial dokumentatua dokumentu sinple gisa idatzi zen, 700 hitz baino gutxiagokoa, eta bertsio horri HTTP/0.9 izena eman zitzaion, GET metodoa bakarrik onartzen zuena, eta horrek bakarrik zerbitzariaren HTML dokumentuak berreskuratzeko aukera ematen zien bezeroei, baina ez zuen onartzen beste fitxategi-formaturik, ezta informazioa kargatzeko ere. Bertsioak ez zuenez POST onartzen, bezeroak ezin zion informazioa bidali zerbitzariari. 
;W3C HTTP lantaldea
:HTTP protokoloaren ezaugarri berriak behar zirela eta RFC ofizial gisa erabat dokumentatu behar zirela erabaki ondoren, 1995. urtearen hasieran HTTP Working Group (HTTP WG, Dave Raggett buru zela) eratu zen, protokoloa estandarizatu eta zabaltzeko, eragiketa zabalagoekin, negoziazio zabalagoarekin, meta-informazio aberatsagoarekin, metodo eta goiburu gehigarrien eremuak gehitzean eraginkorragoa bihurtu zen segurtasun-protokoloarekin lotuta.
:HTTP WGk protokoloaren bertsio berriak berrikusi eta argitaratzeko asmoa zuen, hala nola HTTP/1.0 eta HTTP/1.1, 1995ean, baina, berrikuspen ugarien ondorioz, denbora-lerro horrek urtebete baino askoz gehiago iraun zuen.
:HTTP WGk, halaber, HTTPren bertsio bat zehaztea pentsatu zuen, etorkizun urrunean HTTP-NG (HTTP Next Generation) izenekoa, eta bertsio horrek, besteak beste, aurreko bertsioetako gainerako arazo guztiak konponduko zituen, hala nola, errendimendua, latentzia baxuko erantzunak..., baina lan hau urte batzuk geroago hasi zen eta ez zen inoiz amaitu.
;HTTP/1.0 (1996an argitaratua)
:1996ko maiatzean, RFC 1945 argitaratu zen, aurreko 4 urteetan HTTP/1.0 aurrestandar zirriborro gisa erabili zenaren HTTP/1.0 azken berrikuspen gisa, web-nabigatzaile eta web-zerbitzari askok erabiltzen zutena. 
:1996. urtearen hasieran, garatzaileak HTTP/1.0 protokoloaren luzapen ez-ofizialak (hau da, "keep-alive" konexioak, etab.) sartzen hasi ziren beren produktuetan, HTTP/1.1 espezifikazioen zirriborroak erabiliz.
:GET, HEAD eta POST eskaera-metodoak ahalbidetzen ditu.
;HTTP/1.1 (1997an argitaratua)
:1996ko hasieratik, web-nabigatzaile eta web-zerbitzarien garatzaile nagusiak ere HTTP/1.1 zehaztapen aurreestandarren zirriborroetan zehaztutako ezaugarri berriak ezartzen hasi ziren. Azken erabiltzaileek azkar hartu zituzten nabigatzaile eta zerbitzarien bertsio berriak. 1996ko martxoan, web-ostatuko enpresa batek jakinarazi zuen Interneten erabilitako nabigatzaileen %40ak baino gehiagok HTTP/1.1 "Host" goiburu berria erabiltzen zutela ostatu birtuala gaitzeko. Web-ostatuko enpresa horrek berak jakinarazi zuen 1996ko ekainean, bere zerbitzarietan sartzen ziren nabigatzaile guztien %65ek HTTP/1.1 estandarra betetzen zutela.
:1997ko urtarrilean, RFC 2068 ofizialki argitaratu zen http/1.1 espezifikazio gisa.
:1999ko ekainean, RFC 2616 argitaratu zen, aurreko HTTP/1.1 zehaztapenetan (zaharkituak) oinarritutako hobekuntza eta eguneratze guztiak sartzeko.
;W3C HTTP-NG lantaldea
:Aurreko HTTP Lantaldearen 1995eko plan zaharrari helduz, 1997an lantalde bat osatu zen, HTTP protokolo berri bat garatzeko, HTTP-NG (HTTP Next Genration) izenekoa. Proposamen/zirriborro batzuk egin ziren protokolo berriak HTTP transakzioen multiplexazioa erabil zezan TCP/IP konexio bakar baten barruan, baina 1999an taldeak bere jarduera utzi zuen arazo teknikoak IETFri pasatuz.
;IETF HTTP lantaldea berriro hasi
:2007an, IETFren HTTP Lantaldea (HTTP WG bis edo HTTPbis) berriz hasi zen, lehenik eta behin, aurreko HTTP/1.1 zehaztapenak berrikusteko eta argitzeko, eta, bigarrenik, etorkizuneko HTTP/2 zehaztapenak idazteko eta hobetzeko (httpbis deituak).
;SPDY Googlek garatutako HTTP protokolo ez-ofiziala
:2009an, Googlek, enpresa pribatu batek, SPDY izeneko HTTP protokolo bitar berri bat garatu eta probatu zuela iragarri zuen. Helburu inplizitua web trafikoa izugarri bizkortzea zen (bereziki etorkizuneko web nabigatzaileen eta haien zerbitzarien artean).
:SPDY, egia esan, HTTP/1.1 baino askoz azkarragoa izan zen proba askotan, eta, beraz, Chromium azkar hartu zuen eta, ondoren, beste web nabigatzaile garrantzitsu batzuk.
:TCP/IP konexio bakar baten bidez HTTP fluxuen multiplexazioari buruzko ideietako batzuk hainbat iturritatik hartu ziren, W3C-ko HTTP-NG Lantaldearen lana barne.
;HTTP/2 (2015ean argitaratua)
:2012ko urtarrila-martxoa bitartean, HTTP lantaldeak (HTTPbis) HTTP/2 protokolo berri batean zentratzen hasteko beharra iragarri zuen (HTTP/1.1 espezifikazioen berrikuspena amaitzen zen bitartean), agian SPDYrentzat egindako lana eta ideiak kontuan hartuta.
:Hilabete batzuk HTTP bertsio berri bat garatzeko zer egin eztabaidatu ondoren, SPDYtik eratortzea erabaki zen.
:2015eko maiatzean, HTTP/2 RFC 7540 bezala argitaratu zen, eta berehala onartu zuten SPDY jasaten zuten web-nabigatzaile guztiek eta, astiroago, web-zerbitzariek.
;HTTP/1.1 eguneraketak (2014)
:2014ko ekainean, HTTP lantaldeak sei zatiko HTTP/1.1 zehaztapen eguneratu bat argitaratu zuen,  RFC 2616 zaharkituta utzi zuena:
:* RFC 7230, *HTTP/1.1: Mezu sintaxia eta bideratzea*
:* RFC 7231, *HTTP/1.1: Semantika eta edukia*
:* RFC 7232, *HTTP/1.1: Baldintzapeko eskaerak*
:* RFC 7233, *HTTP/1.1: Eskaera sortak*
:* RFC 7234, *HTTP/1.1: Cachean biltegiratzea*
:* RFC 7235, *HTTP/1.1: Autentifikazioa*
;HTTP/0.9 deprekazioa
:RFC 7230ren A gehigarrian, HTTP/0.9 zaharkituta geratu zen HTTP/1.1 bertsioa (eta goragokoa) onartzen duten zerbitzarientzat:
:*HTTP/0.9k ez zuenez eskabide baten goiburu-eremurik onartzen, ez dago inolako mekanismorik izenetan oinarritutako ostalari birtualak onartzeko (baliabideak hautatzea ostalariko goiburu-eremua ikuskatuz). **Izenetan oinarritutako ostalari birtualak inplementatzen dituen edozein zerbitzarik HTTP/0.9 euskarria desgaitu behar du.** HTTP/0.9 diruditen eskaera gehienak, izan ere, gaizki eraikitako HTTP/1.x eskaerak dira, eskaeraren xedea behar bezala kodetu ez zuen bezero batek eragindakoak.*
:2016az geroztik, produktu-kudeatzaile eta erabiltzaile-agenteen (nabigatzaileak, etab.) eta web-zerbitzarien garatzaile asko hasi dira HTTP/0.9 protokolorako euskarria pixkanaka ez onartzeko eta baztertzeko planak egiten, batez ere arrazoi hauengatik:
:*Hain da sinplea, non RFC dokumentu bat ez zela inoiz idatzi (jatorrizko dokumentua baino ez dago);
:*Ez du HTTP goibururik, eta ez ditu gaur egun gutxieneko segurtasun-arrazoiengatik beharrezkoak diren beste ezaugarri asko;
:*1999-2000 urteetatik ez da orokortu (HTTP/1.0 eta HTTP/1.1 protokoloak direla eta), eta sareko hardware oso zahar batzuetan bakarrik erabiltzen da, hala nola, bideratzaileetan, etab.
;HTTP/3 (2018an argitaratua)
:HTTP/3 proposatutako HTTP/2ren ondorengoa da, eta dagoeneko erabiltzen da webgunean, UDP erabiliz azpiko garraio-protokolorako, TCP erabili beharrean. HTTP/2 bezala, ez dago zaharkitua protokoloaren aurreko bertsio nagusietan. HTTP/3rako euskarria 2019ko irailean gehitu zen Cloudflaren eta Google Chromen, eta Chrome eta Firefoxen bertsio egonkorretan gaitu daiteke.
:2022ko ekainaren 6an, IETFk HTTP/3 estandarizatu zuen RFC 9114 bezala.
;2022ko eguneratzeak eta errefaktorizazioa
:2022ko ekainean, RFC sorta bat argitaratu zen, aurreko dokumentu asko zaharkituta utzi zituena, eta aldaketa txiki batzuk eta HTTP semantikaren deskribapenaren errefaktorizazio bat sartu zituen dokumentu bereizi batean.
:*RFC 9110, HTTP Semantika
:*RFC 9111, HTTP cachean biltegiratzea
:*RFC 9112, HTTP/1.1
:*RFC 9113, HTTP/2
:*RFC 9114, HTTP/3 (ikusi aurreko atala)
:*RFC 9204, QPACK: HTTP/3ko eremuen konpresioa
:*RFC 9218, HTTPrako lehentasun-eskema hedagarria
## Funtzionamendua 
HTTP bezero eta zerbitzari arteko eskaera/erantzun protokolo bat da. HTTP bezero bat, web nabigatzaile bat, esate baterako, eskaera egiten du normalean TCP erabiliz urruneko zerbitzari bateko 80 portura konektatzeko. Ondoren, burualdeak eta MIME luzapenak bidaltzen dira eskatutako dokumentuaren eta konexioaren egoeraren metainformazioarekin. Zerbitzariak honi erantzun egiten dio behar den fitxategia bidaliz, erroreren bat azalduz edo dena delakoa eginez.
Esan beharra dago zerbitzariak ez duela bezeroaren eskaerei buruzko inolako informaziorik gordeko. Hori dela eta HTTP "**egoera gabeko**" protokoloa dela esaten da.

Bezero batek zerbitzari bati eskaera bat egiten dion bakoitzean, hurrengo urratsak egikaritzen dira:
# Erabiltzaile bat URL batera sartzen da, HTML dokumentu baten esteka aukeratuta edo web bezeroaren helbide eremuan zuzenean sartuta.
# Web bezeroak URLa dekodetzen du, haren zatiak bereiziz. Horrela, sarbide-protokoloa, zerbitzariaren DNS edo IP helbidea, balizko aukerako ataka (lehenetsitako balioa 80 da) eta zerbitzariaren eskatutako objektua identifikatzen ditu.
# TCP/IP konexio bat irekitzen da zerbitzariarekin, dagokion TCP portura deituz.
# Eskaera egiten da. Horretarako, beharrezko komandoa (**GET**, **POST**, **HEAD**,...), eskatutako objektuaren helbidea (zerbitzariaren helbidera jarraitzen duen URLaren edukia), erabilitako HTTP protokoloaren bertsioa eta informazio-multzo aldakor bat, nabigatzailearen gaitasunei buruzko datuak, zerbitzariarentzako aukerako datuak eta abar barne hartzen dituena, bidaltzen dira.
# Zerbitzariak erantzuna itzultzen dio bezeroari. Itzulera-informazioaren egoera-kodea eta MIME datu-mota dira, eta, ondoren, informazioa bera.
# TCP konexioa ixten da. *HTTP Keep Alive* modua erabiltzen ez bada, prozesu hori errepikatu egiten da HTTP zerbitzarirako sarbide bakoitzerako.

## HTTP konexioak 
Funtzionamenduan adierazi den bezala, HTTP bezeroak TCP konexio bat ezarri beharko du zerbitzari bateko 80.portuarekin. HTTP konexio hauek bi motatakoak izan daitezke: **iraunkorrak** edo **ez-iraunkorrak**.

**HTTP konexio iraunkorrak:** HTTP bezeroak botatako eskaera ezberdinak TCP konexio berdinean bota eta erantzun egingo dira. Beraz TCP konexio bakar batean HTTP bezeroak eta zerbitzariak objektu bat baino gehiago bidaltzeko aukera izango dute.
HTTP/1.1 bertsioak era honetako konexioak erabiltzen ditu defektuz. Era honetako konexioak erabiliz HTTP eskaeretan erantzun denbora laburragoak lor ditzakegu.

Gainera konexio **iraunkorrak** erabiltzeak beste aukera bat ematen digu: "**Pipelining**" delakoa.
"**Pipelining**" erabiltzen duen konexio iraunkor batek bezeroari eskaerak bata bestearen atzean botatzeko aukera ematen dio aurreko eskaeren erantzun edo baieztapena jaso aurretik. Hau da, HTTP bezeroak eskera bat bota duenean normalean zerbitzariaren erantzuna itxarotera behartuta egongo litzake, "**Pipelining**" darabilen HTTP konexio Iraunkor batean berriz bezeroak eskaerak paraleloan botatzeko aukera izango du aurrekoen erantzuna itxaron gabe, modu horretan azkarragoa izanik. Dena den "**Pipelining**" erabiltzean paraleloan egin ditzakegun konexioak zerbitzari bati mugaturik daude, zerbitzaria blokea ez dadin.

**HTTP konexio ez-iraunkorrak:** HTTP bezero batek eskaera bakoitzeko TCP konexio bat ezarri eta askatu behar izango du. Beraz TCP konexio bakoitzean objektu bakarra bidali ahal izango da.

HTTP/1.0 HTTPren hasierako bertsioak era honetako konexioak erabiltzeko aukera ematen zuen bakarrik.

## HTTP mezuak 
HTTP protokoloak bi mezu mota ditu RFC 1954 eta RFC 2616 estandarretan definituta: eskaerako mezua eta erantzun mezua. Mezu hauek 8 biteko ASCIIan idazten dira, beraz nahiko erraz irakur daitezke.Hona hemen bi mezu hauen egitura eta eremu ezberdinei buruzko azalpenak:

'**Eskaera-mezua:**'

erdian|frame|HTTP eskaera mezuaren formatua.

Adibide bat:

**GET /products/list.html HTTP/1.1**

**Host:** *www.dendabat.eu*

**User-Agent:** *Mozilla/5.0*

**Connection:** *keep alive*

**If-modified-since:** *Mon, 23 Nov 2009 10:43:55 GMT*

**Accept-language:** *eu*

**Cookie:** *dendabat_idusr=SDfla80AABQc28s-f21a381a022f63a5cd2dbf11868*

Adibidean ikus dezakegu GET metodoa erabiltzen dela. Metodo ezberdinak beherago ikusi daitezke. Agertzen zaizkigun goiburu ezberdinen azalpena:

**Host:** zeini egin diogun konexioa

**User-Agent:** web arakatzailearen bertsioa

**Connection:** konexio iraunkorra(Keep Alive) edo konexio ez iraunkorra (close) erabiltzen gaudela adierazteko

**If-modified-since:** eremu honetan data bat sartzen da, hain zuzen ere bezeroak bere "caché" memorian duen objektuaren kopiaren data zehazten duena. Eremu honen bidez **BALDINTZAZKO GET** eskaera bat egiten dugu. Bezeroak bere "caché" memorian duen objektuaren kopiaren data bidaltzean zerbitzariari galdetzen dio ea data horretatik aurrera objektu horretan aldaketarik egon den, aldaketa egon bada zerbitzariak bere erantzun mezuan objektu horren bertsio berria bidaliko dio, aldaketarik egon ez bada zerbitzariak bere erantzun mezuan ez du objekturik bidaliko (gainera erantzun mezua **304 Not Modified** modukoa izango da).

**Accept-language:** web orrialde batek orrialdearen hizkuntza bertsio ezberdinak baditu eremu honen bidez hizkuntza konkretu bat eskatzen zaio( eu-euskara, en-ingelesa, it-italiera…). Eskatzen dugun hizkuntza ez badago defektuz hizkuntzaren orrialde bertsioa itzuliko digu.

**Cookie:** eremu honetan cookie konkretu baten identifikadorea bidali egiten da, gurekin eta eskaera egin diogun webgunearekin erlazionatuta dagoen cookie-arena hain zuzen.
Beste eremu asko daude, baina ezin ditugu denak azaldu.

'**Erantzun mezua:**'

erdian|frame|HTTP erantzun mezuaren formatua.

Adibide bat:

**HTTP/1.1 200 OK**

**Connection close**

**Date:** *Mon, 18 Jan 2010 10:43:55 GMT*

**Server:** *Mathopd/1.3pl7.7*

**Last-Modified:** *Mon, 23 Nov 2009 10:43:55 GMT*

**Set-Cookie:** *DendabatAccountsLocale_session=en*

**Content-Type:** *image/jpeg*

**Content-Length:** *5270*

(lerro zuria)

**Datuak datuak datuak datuak…**

HTTP/1.1 bertsioaren erabateko erantzun baiezkorreko egoera kodea jaso dugu adibidean.
Ikus ditzagun orain agertzen diren goiburuak:

**Connection close:** mezu honekin konexioa itxi egin dela adierazten da.

**Date:** egundo data jartzen da adierazten da eremu honetan.

**Server:** erabiltzen den zerbitzariaren mota.

**Last-Modified:** eskatu egin den objektuaren azkeneko bertsioaren data. **BALDINTZAKO GET** eskaeretan eremu hau objektu bat bidaltzen denean jaso eta gorde egiten da jakiteko zein izan den objektuaren azken bertsio data.

**Set-Cookie:** Gure eskaeran Cookie-aren identifikazioa bidali ez bada gure ordenagailuan ez dugulako, zerbitzariak set-cookie eremu honen bidez cookie-a ezartzeko eskatzen digu eta normalean identifikadore bat pasako digu gure cookie horrentzako.

**Content-Type:** bidali egiten den objektuaren izaera zein den adierazten dugu hemen.

**Content-Length:** bidali egiten den objektuaren tamaina zein den adierazten da, bytetan.
## HTTP Goiburua 
HTTP eskaera edo erantzunetan bidaltzen diren metadatuak dira, uneko transakzioari buruzko funtsezko informazioa emateko. Goiburu bakoitza goiburu-izen batek zehazten du; ondoren bi puntu, zuriune bat eta goiburu horren balioa, eta azkenik orga-itzulera eta lerro-jauzia bat. Lerro zuri bat erabiltzen da goiburuen amaiera adierazteko. Goibururik ez badago, lerro zuriak iraun egin behar du.

Goiburuek malgutasun handia ematen diote protokoloari eta aukera ematen dute funtzio berriak gehitzeko oinarria aldatu beharrik gabe. Horregatik, HTTP bertsioak gertatu ahala, onartutako goiburu gehiago gehitu dira.

Goiburuek metadatuak izan ditzakete eta bezeroak prozesatu behar ditu (adibidez: eskaerari erantzunez, eduki-mota adieraz daiteke), zerbitzariaren  (adibidez: eskatzen duen edukiaren bezeroak onar ditzakeen irudikapen-motak) edo bitartekariak (adibidez, proxy-ek nola kudeatu behar duten cacheak) bidez.

Goiburu batek izan dezakeen mezu-motaren arabera, honela sailka daitezke: eskaera-goiburuak, erantzun-goiburuak eta, bai eskaera batean, bai erantzun batean joan daitezkeen goiburuak.

### Eskaera-goiburuak 
## HTTP/1.1 Eskaeraren/erantzunaren transakzioaren adibidea 
Jarraian, HTTP/1.1 bezero baten eta HTTP/1.1 zerbitzari baten arteko HTTP transakzioaren adibide bat ageri da, www.example.com web orrian exekutatzen dena, 80. portuan. 

### Bezero eskaera 
```http
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
```

Bezeroaren eskaera bat ("Host: hostname" goiburura soilik murritz daitezkeen eskaera-lerroaren eta goiburu batzuen kasua) lerro zuri baten atzetik doa, eta, beraz, eskaera bi lerro amaierekin amaitzen da, bakoitza orga-itzulera batekin, lerro-jauzi bat jarraitzen dioelarik. "Host: hostname" goiburuko balioak IP helbide bakar bat partekatzen duten DNS izen batzuk bereizten ditu, eta izenan oinarritutako ostatu birtuala baimentzen du. HTTP/1.0 aukeran bada ere, HTTP/1.1 ezinbestekoa da. (A "/" (slash) normalean fitxategi bat bilatuko du /index.html bat badago.)
### Zerbitzari erantzuna 
```http
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
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

  
    Orri adibide bat
  
  
    Kaixo mundua, hau HTML dokumentu sinple bat da.
  

```

ETag goiburuko eremua (erakundearen etiketa) erabiltzen da eskatutako baliabidearen cache bertsioa zerbitzariko baliabidearen egungo bertsioaren berdina den zehazteko. `"Content-Type"`-k HTTP mezuak transmititutako datuen Interneteko bitarteko mota zehazten du, eta `"Content-Length"`-k, berriz, bytetan adierazten du haren luzera. HTTP/1.1 web-zerbitzariak dokumentuaren byte-tarte jakin batzuen eskaerei erantzuteko gaitasuna argitaratzen du, `"Accept-Ranges: bytes"` eremua ezarriz. Hori erabilgarria da, baldin eta bezeroak zerbitzariak bidalitako baliabide baten zati batzuk

Goiburuko lerro gehienak aukerakoak dira, baina batzuk nahitaezkoak. `"Content-Length: number"` goiburuak erakunde baten gorputzarekiko erantzun bat falta duenean, HTTP/1.0 akatstzat hartu behar da, baina baliteke HTTP/1.1 errorea ez izatea `"Transfer-Encoding: chunked"` goiburua baldin badu. Zatien transferentzia kodeketa 0-ko tamaina-zatia erabiltzen du edukiaren amaiera markatzeko. HTTP/1.0 aplikazio zahar batzuek ez zuten `"Content-Length"` goiburua erabiltzen, erantzunaren hasieran ez baitzen ezagutzen gorputz-erakundearen luzera, eta, beraz, bezeroari datuak transferitzen jarraitzen zuen zerbitzariak socket-a itxi arte.

`"Content-Encoding: gzip"` bat erabil daiteke bezeroari jakinarazteko gorputz-entitatearen transmititutako datuen zatia gzip algoritmoaren bidez konprimitzen dela.

## Eskaera-metodoak 
thumb|right|Telnet bidez aurkeztutako HTTP/1.1 eskaera. Eskaera-mezua, erantzun-goiburuko atala eta erantzun-gorputza nabarmentzen dira.
HTTP metodoak definitzen ditu (batzuetan aditz gisa ezagutzen dira, baina zehaztapenaren parte batean ere ez du aditzik aipatzen) identifikatutako baliabidean egin nahi den ekintza adierazteko.Baliabide horrek adierazten duena, dela lehendik dauden datuak, dela dinamikoki sortutako datuak, zerbitzariaren inplementazioaren araberakoa da. Sarritan, zerbitzarian dagoen fitxategi bati edo exekutagarri baten irteerari dagokio baliabidea. HTTP/1.0 zehaztapenak GET, HEAD eta POST metodoak definitu zituen, eta HTTP/1.1 zehaztapenak bost metodo berri gehitu zituen: PUT, DELETE, CONNECT, OPTIONS eta TRACE. Edozein bezerok erabil dezake edozein metodo, eta zerbitzaria edozein metodo konbinazio babesteko konfigura daiteke. Bitarteko batentzat metodo bat ezezaguna bada, metodo ez-segurutzat eta ez-idenpotentetzat hartuko da. Zehaztu daitezkeen metodoen kopuruari ez zaio mugarik jartzen, eta, beraz, etorkizuneko metodoak zehaztu daitezke egungo azpiegitura hautsi gabe. Adibidez, WebDAV-ek zazpi metodo berri definitu zituen, eta RFC 5789-k PATCH metodoa zehaztu zuen.

Metodoen izenak case sensitive dira. Hori ez dator bat case sensitive ez diren HTTP goiburuko izenekin.

; GET: GET metodoak eskatzen du helmugako baliabideak bere egoeraren adierazpide bat transferitzea. GET eskaerek datuak berreskuratu besterik ez dute egin behar, eta ez dute beste eraginik izan behar. (Hau beste HTTP metodoei ere aplikatzen zaie) Aldaketarik egin gabe baliabideak berreskuratzeko, GET nahiago da POST baino, URL baten bidez eskura baitaitezke. Horrek markatzeko eta partekatzeko aukera ematen du, eta GET erantzunak cache bidez biltegiratzeko aukera ematen du, banda-zabalera aurreztu dezakeena. W3Ck bereizketa horri buruzko printzipio orientagarriak argitaratu ditu, honako hau esanez: "Web aplikazioen diseinua aurreko printzipioetan oinarritu behar da, baina baita dagozkion mugetan ere".

; HEAD: HEAD metodoak eskatzen du helmugako baliabideak bere egoeraren adierazpide bat transferitzea, GET eskaera baterako bezala, baina erantzunaren gorputzeko irudikapen-daturik gabe. Hori baliagarria da erantzunaren goiburuko adierazpidearen metadatuak berreskuratzeko, adierazpide osoa transferitu behar izan gabe. Erabilpen-kasuen artean daude egiaztatzea ea orri bat eskuragarri dagoen egoera-kodearen bidez, eta berehala aurkitzea fitxategi baten tamaina (`Content-Length`).

; POST: POST metodoak eskatzen du helmugako errekurtsoak eskabidean jasotako adierazpidea prozesatzea, helmugako errekurtsoaren semantikaren arabera. Adibidez, Interneteko foro batean mezu bat argitaratzeko, posta-zerrenda batean harpidetzeko edo online erosketa-transakzio bat osatzeko erabiltzen da.

; PUT: PUT metodoak eskatzen du helmugako baliabideak bere egoera sortu edo eguneratu dezala eskaeran sartutako adierazpideak definitutako egoerarekin. POSTekiko desberdintasun bat da bezeroak helmuga zerbitzarian non dagoen zehazten duela.

; OPTIONS: OPTIONS metodoak helmugako baliabideak onartzen dituen HTTP metodoak transferitzea eskatzen du. Hori erabil daiteke web-zerbitzari baten funtzionaltasuna egiaztatzeko, baliabide espezifiko baten ordez '*' eskatuz.

; TRACE: TRACE metodoak eskatzen du helmugako baliabideak jasotako eskaera erantzunaren gorputzean transferitzea. Horrela, bezero batek bitartekariek zer aldaketa edo gehigarri egin dituzten (baldin badaude) ikus dezake.

; PATCH: PATCH metodoak eskatzen du helmugako errekurtsoaren egoera aldatzea, eskabideari erantsitako adierazpidean zehaztutako eguneratze partzialaren arabera. Horrek banda-zabalera aurreztu dezake fitxategi edo dokumentu baten zati bat eguneratzean, erabat transferitu behar izan gabe.

Helburu orokorreko web-zerbitzari guztiek gutxienez GET eta HEAD metodoak inplementatu behar dituzte, eta espezifikazioak uste du beste metodo guztiak aukerakoak direla.

## Erantzun-kodeak 
Zerbitzari batek igortzen ditu erantzun-kodeak, bezero batek zerbitzariari egindako eskaerari erantzunez. IETFren iruzkinak eskatzeko kodeak (RFC), beste zehaztapen batzuk eta HTTPko aplikazio komun batzuetan erabilitako kode gehigarri batzuk biltzen ditu. Hiru digituz osatuta egoten dira:

* `1xx` Informazio-mezuak
** `100` **Jarraitu**: Orain arteko guztia ondo dagoela adierazten du, eta bezeroak eskaerarekin jarraitu behar duela edo, amaituta badago, ez ikusiarena egin.
** `101` **Protokolo aldaketa**: Bezeroak *Upgrade* eskaeraren goiburu bati erantzunez bidaltzen da eta zerbitzariak erabiltzaile-agenteak proposatutako protokolo-aldaketa onartu egiten duela adierazten du.
** `102` **Prozesaketa** (WebDAV; RFC 2518): Zerbitzariak eskaera jaso duela eta oraindik prozesatzen dagoela adierazten du; beraz, ez dago erantzun erabilgarririk.
** `103` **Lehen aholkua** (RFC 8297): Linkaren goiburuarekin erabiltzeko pentsatuta dago batez ere eta , zerbitzariak erantzun bat prestatzen duen bitartean, erabiltzaile-agenteari aukera ematen dio baliabideak aurrez kargatzen hasteko. 

* `2xx` Eragiketa arrakastatsua
** `200` **OK**: Eskaerak arrakasta izan du.
** `201` **Sortua**: Eskaerak arrakasta izan du eta baliabide berri bat sortu da horren ondorioz. Hori izan ohi da PUT eskaera baten ondoren bidalitako erantzuna.
** `202` **Onartua**: Eskaera onartu da prozesatzeko, baina prozesamendua ez da osatu. Eskabideari kasu egin dakioke edo ez, eta prozesatzen denean atzera bota daiteke.
** `203` **Informazio ez ofiziala**: Eskaera ondo bete da, baina edukia ez da jatorriz eskatutako iturritik lortu, kopia lokal batetik edo hirugarren batetik jaso da.
** `204` **Edukirik gabe**: Eskaera ondo bete da, baina erantzunak ez du edukirik. Hala ere, goiburua erabilgarria izan daiteke.
** `205` **Reset-erako edukia**: Eskaera ondo bete da, baina erantzunak ez du edukirik, eta, gainera, erabiltzaile-agenteak eskaera egin duen orrialdea berrabiarazi behar du. Erabilgarria da erabiltzaileak bidali ondoren edukia ezabatu behar duten inprimakiak dituzten orrietarako.
** `206` **Eduki partziala**: Eskaerak eskatutako edukiaren zati bat emango du. Ezaugarri hori deskarga-tresnek erabiltzen dute, hala nola wget, aurretik etendako deskargen transferentziarekin jarraitzeko, edo deskarga bat zatitzeko eta zatiak aldi berean prozesatzeko.
** `207` **Egoera-Anitza** (WebDAV; RFC 4918): Hainbat baliabideri buruzko informazioa transmititzen du, zenbait estatu-kode egokiak izan daitezkeen egoeretan. Eskaeraren gorputza XML mezu bat da.
** `208` **Dagoeneko jakinarazia** (WebDAV; RFC 5842): DAV elementuen zerrenda aldez aurretik jakinarazi zen, eta, beraz, ez dira berriro zerrendatuko.
** `226` **Erabilita nago** (RFC 3229): Zerbitzariak GET eskaera bat bete du errekurtsoa jartzeko, eta erantzuna instantziari aplikatutako instantzia-manipulazio baten edo gehiagoren emaitza da.

* `3xx` Beste URL baterako berbideraketa
** `300` **Aukera anizkoitza**: Eskaera honek erantzun posible bat baino gehiago du. Erabiltzaile-agenteak edo erabiltzaileak horietako bat aukeratu behar du. Ez dago erantzunetako bat hautatzeko modu estandarizaturik.
** `301` **Aldaketa iraunkorra**: Eskatutako errekurtsoaren URIa aldatu egin dela esan nahi du. Seguruenik, URI berri bat itzuliko da erantzunean.
** `302` **Aurkituta**: Eskatutako URI errekurtsoa aldi baterako aldatu dela esan nahi du. URIan aldaketa berriak egingo dira etorkizunean. Beraz, URI bera erabili behar du bezeroak etorkizuneko eskaeretan.
** `303` **Beste batzuk ikusi**: Zerbitzariak erantzun hau bidaltzen du bezeroa beste helbide batera bideratzeko, GET eskaera bat erabiliz.
** `304` **Aldatu gabea**: Cache helburuetarako erabiltzen da. Zerbitzariak bezeroari adierazten dio erantzuna ez dela aldatu. Orduan, bezeroak bere cachean gordetako bertsio bera erabiltzen jarrai dezake.
** `305` **Proxy bat erabili**: HTTP protokoloaren zehaztapenaren aurreko bertsio batean definitu zen, eskatutako erantzun bat proxy batetik sartu behar dela adierazteko. Zaharkituta geratu da, proxy baten konfigurazioari dagozkion segurtasun-kezkengatik.
** `306` **Proxy-a aldatu**: Zaharkituta geratu da. HTTP/1.1 espezifikazioaren aurreko bertsioetan erabili zen.
** `307` **Denborazko berbideraketa**: Zerbitzariak erantzun hori bidaltzen dio bezeroari, eskatutako baliabidea beste URI batera bideratzeko, aurreko eskaera erabili zen metodo berarekin. HTTP 302 Aurkituta erantzun-kodearen semantika bera du salbuespen batekin: erabiltzaileak ez du aldatu behar erabilitako HTTP metodoa.
** `308` **Berbideraketa iraunkorra**: Baliabidea beste URI batean iraunko dagoela esan nahi du, *HTTP Location* goiburuko erantzunean zehaztua. HTTP 301 Aldaketa iraunkorra erantzun-kodearen semantika bera du salbuespen batekin: erabiltzaile agenteak ez du aldatu behar erabilitako HTTP metodoa.

* `4xx` Bezeroaren aldeko errorea
** `400` **Eskaera ezegokia** : Zerbitzariak ezin izan zuela eskabidea interpretatu esan nahi du, sintaxi baliogabea zela eta.
** `401` **Baimenik ez** Beharrezkoa da autentifikatzea eskatutako erantzuna lortzeko. 403ren antzekoa da, baina kasu honetan, autentifikazioa posible da.
** `402` **Ordainketa beharrezkoa**: Etorkizuneko erabileretarako gordeta dago. Kodea sortzeko hasierako helburua ordainketa-sistema digitaletan erabiltzeko izan zen. Hala ere, gaur egun ez da erabiltzen.
** `403` **Debekatua**: Bezeroak ez ditu eduki jakin baterako behar diren baimenak, eta, beraz, zerbitzariak uko egiten dio erantzun egokia emateari.
** `404` **Ez da aurkitu**: Zerbitzariak ezin izan du aurkitu eskatutako edukia. Ospetsuenetako bat da, webean duen agerpen handiagatik.
** `405` **Baimendu gabeko metodoa**: Eskatutako metodoa ezagutzen du zerbitzariak, baina desgaitua izan da eta ezin da erabili. Derrigorrezko bi metodoak, GET eta HEAD, ez dira inoiz desgaitu behar eta ez lukete itzuli behar 405 errore-kodea.
** `406` **Ez onargarria**: Zerbitzariak eduki zerbitzari-bultzatuaren negoziazioa aplikatu ondoren, erabiltzaileak emandako irizpidearen araberako edukirik aurkitzen ez duenean erabiltzen da.
** `407` **Proxy beharrezkoa**: 401 kodearen antzekoa, baina autentifikazioa proxy batetik abiatuta egin behar da.
** `408` **Itxarote denbora iragan da**: Zenbait zerbitzaritan konexio ez-aktibo batean bidaltzen da, baita bezeroak aldez aurretik eskaerarik egin gabe ere. Zerbitzariak konexio hau deskonektatu nahi duela erabili gabe esan nahi du.
** `409` **Gatazka**: Eskaera bat zerbitzariaren egungo egoerarekin gatazkan dagoenean bidal daiteke.
** `410` **Desagertuta**: Eskatutako edukia zerbitzaritik ezabatu denean bidal daiteke.
** `411` **Luzera beharrezkoa**: Zerbitzariak ez du eskaera onartzen, *Content-Length* izenburuaren eremua zehaztuta ez dagoelako eta zerbitzariak hala eskatzen duelako.
** `412` **Aurrebaldintzak huts egin du**: Bezeroak aurrebaldintzak adierazten ditu goiburuetan, zerbitzariak betetzen ez dituenak.
** `413` **Eskaera entitate luzeegia**: Eskaera-entitatea luzeagoa da zerbitzariak zehaztutako mugak baino; zerbitzariak konexioa itxi dezake edo *Retry-After* goiburu-eremua itzul dezake.
** `414` **Eskaera URI luzeegia**: Bezeroak eskatutako URIa zerbitzaria interpretatzeko prest dagoena baino luzeagoa da.
** `415` **Baliogabeko multimedia mota**: Eskatutako datuen multimedia-formatua ez du zerbitzariak onartzen, eta, beraz, zerbitzariak ez du eskaera onartzen.
** `416` **Eskatutako tartea ez dago eskuragarri**: Eskaeran *Range* goiburuaren eremuak zehaztutako tarteak ez du betetzen; litekeena da barrutia URIren xede-datuen tamainatik kanpo egotea.
** `417` **Itxaropen huts egin**: Horrek esan nahi du eskatutako *Expect* goiburuaren eremuan adierazitako itxaropen ezin duela zerbitzariak bete.
** `418` **Teontzia naiz** (RFC 2324, RFC 7168): Zerbitzariak uko egiten dio teontzi batekin kafea egiteari.
** `421` **Gaizki zuzendutako eskaera**: Eskaera erantzun bat emateko gai ez den zerbitzari bati zuzendu zaio.
** `422` **Entitate prozesaezina**: Eskaera ondo osatuta dago, baina ezin izan da jarraitu semantika-akatsen ondorioz.
** `423` **Blokeatuta** (WebDAV; RFC 4918): Sartzen ari garen baliabidea blokeatuta dago.
** `424` **Mendekotasun akatsa** (WebDAV; RFC 4918): Eskaerak huts egiten du, aurreko eskaera batek huts egin duelako.
** `426` **Eguneraketa beharrezkoa**: Zerbitzariak uko egiten dio eskaera uneko protokoloa erabiliz aplikatzeari, baina prest egon daiteke bezeroa beste protokolo batera eguneratu ondoren. Zerbitzariak *Upgrade* goiburu bat bidaltzen du erantzun batean, eskatutako protokoloak adierazteko.
** `428` **Aurrebaldintza beharrezkoa** (RFC 6585): Jatorrizko zerbitzariak eskaera baldintzapekoa izatea eskatzen du. 'Eguneratze galdua' arazoak saihesteko asmoa du. Bezero batek baliabidearen egoera lortzen du, aldatu egiten du, eta zerbitzariari itzultzen dio, hirugarren batek zerbitzariaren egoera aldatu eta gatazka bat sortzen duen bitartean.
** `429` **Eskaera gehiegi** (RFC 6585): Erabiltzaileak eskaera gehiegi bidali ditu denboraldi jakin batean.
** `431` **Eskaera goiburu eremu luzeegiak** (RFC 6585): Zerbitzaria ez dago eskaera prozesatzeko prest, goiburuko eremuak luzeegiak direlako.
** `451` **Eskurazin legez kanpoko arrazoiengatik** (RFC 7725): Erabiltzaileak legez kanpoko baliabide bat eskatzen du, gobernuren batek zentsuratutako web orriren bat bezala. 451 kodea Fahrenheit 451 eleberriaren erreferentzia gisa aukeratu zen.

* `5xx` Zerbitzariaren aldeko errorea
** `500` **Barne zerbitzari errorea**: Zerbitzariak nola maneiatu ez dakien egoera bat aurkitu du.
** `501` **Inplementatu gabea**: Eskatutako metodoa ez du zerbitzariak onartzen edota ezagutzen eta ezin da erabili.
** `502` **Igarobide ezegokia**: Zerbitzariak eskaera maneiatzeko beharrezko erantzun bat lortzeko lotura-ate gisa lan egiten duen bitartean, baliogabeko erantzun bat jaso zuen.
** `503` **Zerbitzua ez dago eskuragarri**: Zerbitzariak ezin du eskaera kudeatu gainkargatuta edo mantentze-lanetarako ez-aktibo dagoelako.
** `504` **Igarobideko itxarote denbora iragan da**: Zerbitzaria lotura-ate gisa jokatzen ari denean eta garaiz erantzun ezin duenean gertatzen da.
** `505` **Baliogabeko HTTP bertsioa**: Zerbitzariak ez du eskaeran erabilitako HTTP bertsioa onartzen.
** `506` **Saihesbidea ere negoziatzen** (RFC 2295): Eskaerarako eduki gardeneko negoziazioa erreferentzia zirkularra da.
** `507` **Biltegiratze eskasa** (WebDAV; RFC 4918): Aukeratutako baliabidearen aldagaia eduki gardeneko negoziazioa bera akoplatzeko konfiguratuta dago, eta, beraz, ez da negoziazio-prozesurako azken puntu egokia.
** `508` **Zikloa deteketatua** (WebDAV; RFC 5842): Zerbitzariak ziklo infinitu bat detektatzen du eskaera prozesatzen ari dela.
** `510` **Zabaldu gabe** (RFC 2774): Eskaerarako luzapen gehigarriak eskatzen dira zerbitzariak bete ditzan.
** `511` **Sare autentifikazioa beharrezkoa** (RFC 6585): Bezeroak sarerako sarbidea lortzeko autentifikatu egin behar duela adierazten du.

## Oharrak
## Erreferentziak 
## Kanpo estekak 
*  RFC-1945
*  RFC-1954
*  RFC-2068
*  RFC-2145
*  RFC-2295
*  RFC-2324
*  RFC-2518
*  RFC-2616
*  RFC-2774
*  RFC-3229
*  RFC-4918
*  RFC-5789
*  RFC-5842
*  RFC-6585
*  RFC-7168
*  RFC-7230
*  RFC-7231
*  RFC-7232
*  RFC-7233
*  RFC-7234
*  RFC-7235
*  RFC-7540
*  RFC-7725
*  RFC-8297
*  RFC-9110
*  RFC-9111
*  RFC-9112
*  RFC-9113
*  RFC-9114
*  RFC-9204
*  RFC-9218
*  W3Cren zehaztapenak HTTP protokoloaren inguruan
*  HTML oinarrizko gida
*  HTML etiketen zerrenda
*  MDN Códigos de estado de respuesta HTTP
*  Capítulo 5: Protocolo HTTP