HTTP

Sare eta teknologia protokoloak*

Aplikazio geruza	DNS, FTP, HTTP, HTTPS, IMAP, IRC, NFS, NNTP, NTP, POP3, SMB/CIFS, SMTP, SNMP, SSH, Telnet, SIP, gehiago
Aurkezpen geruza	ASN.1, MIME, SSL/TLS, XML, gehiago
Saio geruza	NetBIOS, gehiago
Garraio geruza	SCTP, SPX, TCP, UDP, gehiago
Sare geruza	AppleTalk, IP, IPX, NetBEUI, X.25, gehiago
Lotura geruza	ATM, Ethernet, Frame Relay, HDLC, PPP, Token Ring, Wi-Fi, STP, gehiago
Geruza fisikoa	Kable ardazkide, Zuntz optiko, Pare kordatu, Mikrouhin-sarea, Irrati bidezko sarea, RS-232, gehiago
*OSI ereduaren arabera

HTTP edo HyperText Transfer Protocol (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.

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.

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.

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:

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.

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

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

Goiburuaren izena	Deskribapena	Adibidea	Egoera
Accept	Onartzen diren Content-Types (eduki-motak).	Accept: text/plain	Iraunkorra
Accept-Charset	Onartzen diren karaktereen multzoa.	Accept-Charset: utf-8	Iraunkorra
Accept-Encoding	Onartzen diren kodifikazioen zerrenda.	Accept-Encoding: gzip, deflate	Iraunkorra
Accept-Language	Onartzen diren hizkuntzak.	Accept-Language: en-US	Iraunkorra
Accept-Datetime	Onartzen diren orduaren eta egunaren bertsioa.	Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT	Behin-behinekoa
Authorization	Baimen-agiriak.	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==	Iraunkorra
Caché-Control	Cache politikak kontrolatzen dira.	Cache-Control: no-cache	Iraunkorra
Connection	Konexio-mota kontrolatzen da.	Connection: keep-alive Connection: Upgrade	Iraunkorra
Cookie	Aurrez zerbitzariak bidalitako cookie bat, Set-Cookie erabiliz.	Cookie: $Version=1; Skin=new;	Iraunkorra: Estandarra
Content-Length	Eskaeraren edukiaren tamaina byte-tan.	Content-Length: 348	Iraunkorra
Content-MD5	Edukiari buruzko checksum bat MD5 formatuan.	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==	Zaharkitua
Content-Type	POST edo PUTeko eskaeraren eduki-mota.	Content-Type: application/x-www-form-urlencoded	Iraunkorra
Date	Eskaeraren data eta ordua.	Date: Tue, 15 Nov 1994 08:12:31 GMT	Iraunkorra
Forwarded	Proxy bidez konektatuz gero, bezeroaren jatorrizko informazioa adierazten du.	Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17	Iraunkorra
From	Eskaeraren helbide elektronikoa.	From: user@example.com	Iraunkorra
Host	Domeinuaren izena edo IP helbidea (portu-zenbakia izan dezake). Goiburua nahitaez erabili behar da HTTP 1.1etik aurrera.	Host: en.wikipedia.org:8080 Host: en.wikipedia.org	Iraunkorra
Max-Forwards	Mezuak proxietatik zenbat aldiz bidaiatzen duen mugatzen du.	Max-Forwards: 10	Iraunkorra
Origin	Zerbitzarietarako eskaera bat hasten du, Access-Control-Allow-Origin-i erantzunez.	Origin: http://www.example-social-network.com	Iraunkorra: Estandarra
Pragma	Goiburuak ezartzen ditu, zeinetan efektu ugari aplikatzen zaizkio guztiari.	Pragma: no-cache	Iraunkorra
Proxy-Authorization	Proxy bat konektatzeko baimen-kredentzialak.	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==	Iraunkorra
Range	Edukiaren zati bat bakarrik eskatzen du.	Range: bytes=500-999	Iraunkorra
Referer [sic]	Jatorria duen URL helbidea adierazten du, bestela esanda, atzera botoiaren web-helbidea.	Referer: http://en.wikipedia.org/wiki/Main_Page	Iraunkorra
User-Agent	Eskaeraren informazioa du, hala nola nabigatzailea, sistema eragilea eta abar.	User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0	Iraunkorra
Upgrade	Zerbitzariari HTTP bertsioa eguneratzeko eskatzen dio, funtziona dezan.	Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket	Iraunkorra
Warning	Erakundearen arazoei buruzko ohar orokorra.	Warning: 199 Miscellaneous warning	Iraunkorra

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

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

\n\n"}}" id="mwArs">

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>

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 bakarrik eduki behar baditu, byte zerbitzua deitua. "Connection: close" bidaltzen denean, web-zerbitzariak TCP konexioa itxiko duela esan nahi du, erantzun honen transferentzia amaitu eta berehala.

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

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.

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.

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.

Eskaera metodoen propietateak

Eskaera metodoa	RFC	Eskaerak karga erabilgarriko gorputza du	Erantzunak karga erabilgarriko gorputza du	Segurua	Idenpotentea	Miatzeko modukoa
GET	RFC 9110	Aukerazkoa	Bai	Bai	Bai	Bai
HEAD	RFC 9110	Aukerazkoa	Ez	Bai	Bai	Bai
POST	RFC 9110	Bai	Bai	Ez	Ez	Bai
PUT	RFC 9110	Bai	Bai	Ez	Bai	Ez
DELETE	RFC 9110	Aukerazkoa	Bai	Ez	Bai	Ez
CONNECT	RFC 9110	Aukerazkoa	Bai	Ez	Ez	Ez
OPTIONS	RFC 9110	Aukerazkoa	Bai	Bai	Bai	Ez
TRACE	RFC 9110	Ez	Bai	Bai	Bai	Ez
PATCH	RFC 5789	Bai	Bai	Ez	Ez	Ez

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.

Kanpo estekak

• (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

• Datuak: Q8777
• Multimedia: Hypertext Transfer Protocol / Q8777