HTTP
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 [1]. Bertsio hori geroago garatu zen, azkenean 1.0 publiko bihurtuz.[2]
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.[3]1997an eboluzionatu egin zuen (1.1 bertsio gisa), eta gero haren zehaztapenak 1999, 2014 eta 2022an eguneratu ziren.[4]
HTTPS izeneko aldaera segurua webguneen %85ek baino gehiagok erabiltzen dute.[5] HTTP/2, 2015. urtean argitaratua, HTTPren semantikaren adierazpen eraginkorragoa eskaintzen du igorpenean. 2023ko apirilera arte, webguneen %39k erabiltzen dute,[6] eta ia web nabigatzaile guztiek (erabiltzaileen %97k baino gehiagok) babesten dute.[7] Garraio Geruzako Segurtasunari (TLS) buruzko web-zerbitzari nagusiek ere onartzen dute, Aplikazioa Geruza-protokoloaren negoziazio-luzapen bat erabiliz (ALPN)[8], non TLS 1.2 edo handiagoa behar den.[9]
HTTP/3, HTTP/2ren ondorengoa, 2022an argitaratu zen.[10] Gaur egun, webguneen %26 baino gehiagotan erabiltzen da,[11] eta bateragarria da web nabigatzaile gehienekin, hau da, bateragarria da (partzialki behintzat) web nabigatzaileen %94rekin.[12] 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,[13][14] eta Firefoxen ere gaituta dago.[15] 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).[16]
Historia
aldatuHipertestu 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
aldatuHTTPk 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:
- 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.
Funtzionamendua
aldatuHTTP 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]
- 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
aldatuFuntzionamenduan 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
aldatuHTTP 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:'
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:'
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
aldatuHTTP 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
aldatuGoiburuaren 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
|
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
|
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
aldatuJarraian, 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]
Bezero eskaera
aldatuGET / 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
aldatuHTTP/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[20] 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.[39]
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
aldatuHTTP 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]
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
aldatuZerbitzari 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-mezuak100
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 arrakastatsua200
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 berbideraketa300
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 errorea400
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 errorea500
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
aldatuErreferentziak
aldatu- ↑ (Ingelesez) The Original HTTP as defined in 1991. 1991-01-01.
- ↑ (Ingelesez) Basic HTTP as defined in 1992. (Noiz kontsultatua: 2021-10-19).
- ↑ RFC 1945 ean zehaztapen hori HTTP/1.1.-k gainditu zuen.
- ↑ RFC 2068 (1997) zaharkitua geratu zen RFC 2616 izan zen 1999an, eta RFC 7230 izan zen zaharkitua RFC 9110 izan zen 2022an.
- ↑ Usage Statistics of Default protocol https for websites. .
- ↑ Usage Statistics of HTTP/2 for websites. (Noiz kontsultatua: 2023-04-20).
- ↑ Can I use... Support tables for HTML5, CSS3, etc. (Noiz kontsultatua: 2022-10-16).
- ↑ Friedl, S.; Popov, A.; Langley, A.; Stephan, E.. (July 2014). Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. doi: ..
- ↑ Benjamin, David. Using TLS 1.3 with HTTP/2. (Noiz kontsultatua: 2020-06-02)
Aipua: «This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.». - ↑ HTTP/3. 6 June 2022 (Noiz kontsultatua: 2022-06-06).
- ↑ Usage Statistics of HTTP/3 for websites. (Noiz kontsultatua: 2023-07-20).
- ↑ Can I use... Support tables for HTML5, CSS3, etc. (Noiz kontsultatua: 2023-07-20).
- ↑ Cimpanu, Catalin. (26 September 2019). Cloudflare, Google Chrome, and Firefox add HTTP/3 support. (Noiz kontsultatua: 27 September 2019).
- ↑ (Ingelesez) HTTP/3: the past, the present, and the future. 2019-09-26 (Noiz kontsultatua: 2019-10-30).
- ↑ Firefox Nightly supports HTTP 3 – General – Cloudflare Community. 2019-11-19 (Noiz kontsultatua: 2020-01-23).
- ↑ (Ingelesez) HTTP/3 is Fast. (Noiz kontsultatua: 2022-07-01).
- ↑ (Ingelesez) Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server. LivingInternet (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Berner-Lee, Tim. daemon.c - TCP/IP based server for HyperText. (Noiz kontsultatua: 2023-11-14).(1990-10-02)
- ↑ (Ingelesez) Berner-Lee, Tim. HyperText Transfer Protocol. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).
- ↑ a b c (Ingelesez) Berner-Lee, Tim. The Original HTTP as defined in 1991. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).(1991-01-01)
- ↑ (Ingelesez) Berner-Lee, Tim. Basic HTTP as defined in 1992. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).(1992)
- ↑ (Ingelesez) Raggett, Dave. Dave Raggett's Bio. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Raggett, Dave; Berners-Lee, Tim. Hypertext Transfer Protocol Working Group. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Raggett, Dave. HTTP WG Plans. World Wide Web Consortium (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) HTTP-NG Working Group. World Wide Web Consortium 1997 (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Web Administrator. (2007). HTTP Working Group. IETF (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Web Administrator. (2007). HTTP Working Group: charter httpbis. IETF (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) SPDY: An experimental protocol for a faster web. 2009-11-01 (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Rechartering httpbis. IETF; HTTP WG 2012-01-24 (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) IESG Secretary. (2012-03-19). WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis). IETF; HTTP WG (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Ilya Grigorik; Surma. (2019-09-03). High Performance Browser Networking: Introduction to HTTP/2. Google Inc. (Noiz kontsultatua: 2023-11-14).
- ↑ (Ingelesez) Matt Menke. (2016-06-30). Intent to Deprecate and Remove: HTTP/0.9 Support. (Noiz kontsultatua: 2023-11-15).
- ↑ (Ingelesez) Bishop, Mike. Hypertext Transfer Protocol Version 3 (HTTP/3). (Noiz kontsultatua: 2023-11-15).
- ↑ (Ingelesez) Cimpanu, Catalin. HTTP-over-QUIC to be renamed HTTP/3. ZDNet (Noiz kontsultatua: 2023-11-15).
- ↑ (Ingelesez) Cimpanu, Catalin. Cloudflare, Google Chrome, and Firefox add HTTP/3 support. ZDNet (Noiz kontsultatua: 2023-11-15).
- ↑ (Ingelesez) HTTP/3: the past, the present, and the future. The Cloudflare Blog 2023-11-15 (Noiz kontsultatua: 2023-11-15).
- ↑ (Ingelesez) Firefox Nightly supports HTTP 3. Cloudflare Community 2019-11-06 (Noiz kontsultatua: 2023-11-15).
- ↑ (Gaztelaniaz) CAPÍTULO 5: PROTOCOLO HTTP. (Noiz kontsultatua: 2023-11-15).
- ↑ RFC 9112, HTTP/1.1. .
- ↑ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. Hypertext Transfer Protocol – HTTP/1.0. IETF, 30–32 or..
- ↑ RFC 2616. , 51–57 or..
- ↑ RFC 9112, HTTP/1.1. .
- ↑ a b RFC 9110, HTTP Semantics. .
- ↑ RFC 9110, HTTP Semantics. .
- ↑ Fielding, R.; Nottingham, M.; Reschke, J.. (June 2022). HTTP Semantics. IETF.
- ↑ Jacobs, Ian. (2004). «URIs, Addressability, and the use of HTTP GET and POST» Technical Architecture Group finding (Noiz kontsultatua: 26 September 2010).
- ↑ a b c RFC 9110, HTTP Semantics. .
- ↑ Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections. CERT Coordination Center 2002-05-17 (Noiz kontsultatua: 2007-05-10).
- ↑ Dusseault, Lisa; Snell, James M.. (March 2010). PATCH Method for HTTP. IETF.
Kanpo estekak
aldatu- (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