HTTP

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.[17][18] Erabilitako protokoloak metodo bakarra zuen, GET izenekoa, zerbitzari bati orri bat eskatuko ziona.[19] Zerbitzariaren erantzuna beti HTML orrialde bat zen.[20]

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.

Bertsioa	Sartutako urtea	Uneko egoera
HTTP/0.9	1991	Zaharkitua
HTTP/1.0	1996	Zaharkitua
HTTP/1.1	1997	Estandar
HTTP/2	2015	Estandar
HTTP/3	2018	Estandar

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. [20]

HTTP/1.0 zirriborroa

1992az geroztik, dokumentu berri bat idatzi zen oinarrizko protokoloaren hurrengo bertsio osorako bilakaera zehazteko. Bai 0,9 bertsioko eskaera sinplearen metodoa, bai GET eskaera osoa, bezeroaren HTTP bertsioa barne, onartzen zituen. Hau izan zen HTTP/1.0 azken lanaren zirriborro ez-ofizial guztien lehena.[21]

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.[22][23]

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.[24]

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.[25]

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).[26][27]

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.[28]

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.[29][30]

Hilabete batzuk HTTP bertsio berri bat garatzeko zer egin eztabaidatu ondoren, SPDYtik eratortzea erabaki zen.[31]

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:[32]

• 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,[33][34] 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,[35][36] eta Chrome eta Firefoxen bertsio egonkorretan gaitu daiteke.[37]

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

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:[38]

1. Erabiltzaile bat URL batera sartzen da, HTML dokumentu baten esteka aukeratuta edo web bezeroaren helbide eremuan zuzenean sartuta.
2. 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.
3. TCP/IP konexio bat irekitzen da zerbitzariarekin, dagokion TCP portura deituz.
4. 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.
5. Zerbitzariak erantzuna itzultzen dio bezeroari. Itzulera-informazioaren egoera-kodea eta MIME datu-mota dira, eta, ondoren, informazioa bera.
6. TCP konexioa ixten da. HTTP Keep Alive modua erabiltzen ez bada, prozesu hori errepikatu egiten da HTTP zerbitzarirako sarbide bakoitzerako.

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 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:'

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:'

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

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. [Oharra 1][Oharra 2]

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

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

<html>
  <head>
    <title>Orri adibide bat</title>
  </head>
  <body>
    <p>Kaixo mundua, hau HTML dokumentu sinple bat da.</p>
  </body>
</html>

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[40] GET, HEAD eta POST metodoak definitu zituen, eta HTTP/1.1 zehaztapenak[41] 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.[42][43] Hori ez dator bat case sensitive ez diren HTTP goiburuko izenekin.[44]

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)[45] 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"[46].

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.[47]

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.[47]

DELETE

DELETE metodoak helmugako baliabideak bere egoera ezabatzea eskatzen du.

CONNECT

CONNECT metodoak eskatzen du bitartekariak TCP/IP tunel bat ezartzea eskaeraren xedearen arabera identifikatutako jatorrizko zerbitzarirantz. Askotan HTTP proxy zerbitzari baten edo gehiagoren bidez TLS konexioak babesteko erabiltzen da. Kontsultatu HTTP CONNECT metodoa.[47][48]

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.[49]

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

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.

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