From Wikipedia, the free encyclopedia
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.
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 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]
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]
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 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]
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:'
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 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.
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
|
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 |
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
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.)
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[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.
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]
Content-Length
).
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 |
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.Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.