En la mondo de TTT-evoluo, HTTP-eraraj kodoj ludas esencan rolon por influi la uzantan sperton kaj reputacion de retejo. En ĉi tiu artikolo, ni konsideros kompletan liston de servilaj erarkodoj, analizos iliajn signifojn kaj lernos kiel efike interpreti servilaj respondkodoj por solvi problemojn kaj optimumigi la agadon de la retejo-aplikoj.
Kio estas HTTP-responda kodo
HTTP-respondkodo estas la lingvo de retserviloj, kiu tradukas retumilpetojn en kompreneblajn instrukciojn. Ĝi estas kiel poeto respondanta virtualajn demandojn, donante al ili signifon kaj direkton. Respondkodoj ne ĉiam estas HTTP-eraraj kodoj. Ekzemple, "200 OK" signifas, ke ĉio estas en ordo, sed HTTP-Eraro "404 Not Found" signifas kiam la paĝo estas perdita en la virtuala spaco. Ĉiu kodo estas unika esprimo de la servila stato, kies malkodado permesas al ni kompreni, kio okazas aliflanke de la virtuala mondo.
1xx-kodoj (Informoj)
1xx-statuskodoj en la HTTP-protokolo estas speco de unua ligo en la dialogo inter la servilo kaj la kliento. Anstataŭ provizi kompletan respondon al peto, ili disponigas informojn pri la nuna stato, igante datumŝanĝon pli efika. Ni rigardu ilin pli detale:
100 Daŭrigu . HTTP-respondkodo en kiu la servilo donas la verdan lumon al la uzanto, permesante al li sekure daŭrigi sendi grandan peton.
101 Ŝanĝado de Protokoloj . La servilo informas la klienton, ke ĝi ŝanĝas la regulojn de la ludo, ekzemple, moviĝante de HTTP al la pli sekura HTTPS. En ĉi tiu kazo, la kaplinio "Ĝisdatigo" estas uzata por la protokolŝanĝo.
102 Prilaborado . Ĉi tiu kodo estas kiel mesaĝo, ke la servilo akceptis la peton, sed ankoraŭ estas okupata pri kompleksa operacio.
103 Fruaj Sugestoj . Ĉi tie la servilo sendas plurajn indikajn kapliniojn al la kliento antaŭ la ĉefa respondo, avertante pri io, kio povus esti grava en la proksima estonteco.
2xx kodo (Sukcesa)
HTTP-eraraj kodoj en la grupo 2xx indikas sukcesan peton de la servilo. Ili esence funkcias kiel "verda lumo" en la amplekso de interretaj komunikadoj, konfirmante, ke ĉio iras laŭplane kaj sukcese finiĝis.
200 OK . Ĉi tiu stato estas uzata kiam la servilo prilaboras peton per la GET-metodo senprobleme kaj redonas la petitajn datumojn kiel respondon. La kaplinio "Content-Type" raportas la enhavtipon en la respondo. Ĝi nur informas la klienton, ke la peto sukcesis.
201 Kreita . Ĉi tie la servilo anoncas la kreon de nova rimedo.
202 Akceptita . La servilo sciigas la uzanton, ke la peto estas akceptita, sed bezonos tempon por respondi.
203 Ne-aŭtoritataj informoj . Ĉi tiu kodo provizas al la kliento datumojn, kiuj eble ne estas oficialaj, sed povas esti uzataj por komparo.
204 Neniu Enhavo . La servilo prilaboris la peton sed ne redonas ian ajn plian enhavon.
205 Restarigi Enhavon . Ĉi tie la kliento estas instrukciita restarigi la nunan vidon aŭ datumojn post sendado.
206 Parta Enhavo . Ĉi tiu kazo indikas, ke la respondo enhavas nur parton de la petita enhavo. La titolo "Content-Range" indikas la partan enhavintervalon.
207 Plurstato. La servilo sukcese plenumis pluroperacian peton de la kliento, kaj la respondo enhavas informojn pri la stato de ĉiu el la operacioj.
226 IM Uzita . Ĉi tiu kodo indikas, ke la servilo uzis la metodon Incremental Metadata (IM) kaj respondis pasante nur la modifitajn rimedajn partojn al la kliento.
3xx-kodoj (alidirektiloj)
3xx-kodoj en la HTTP-protokolo estas kiel montriloj, kiuj gvidas la uzanton al nova rimedloko. Ili informas la klienton, ke sekvaj paŝoj devas esti prenitaj por akiri la petitan enhavon aŭ por esti redirektitaj al alia rimedo. Ni mergu en la detalojn de ĉiu el ili:
300 Multoblaj Elektoj . La kliento ricevas signalon, ke ekzistas pluraj eblaj lokoj por la rimedo kaj ricevas elekton kiel respondon. En nunaj cirkonstancoj, la titolo "Loko" povas indiki alternativajn opciojn por la rimedo.
301 Movita Permanente. La servilo raportas al la uzanto, ke la rimedo estis permanente movita al alia loko.
302 Trovita . Ĉi tiu HTTP-kodo similas al provizora alidirekto. La servilo informas la konsumanton, ke la rimedo estas provizore havebla ĉe malsama URL. La kaplinio "Loko" montras al la nova URL por la provizora alidirekto.
303 Vidu Alia . La kliento estas informita, ke la rimedo estas havebla ĉe malsama URL kaj devas fari GET-peton al tiu nova adreso.
304 Ne Modifita . Ĉi tiu stato informas la klienton, ke la rimedo restis senŝanĝa ekde la lasta peto kaj ne bezonas esti elŝutita denove. Kiam oni faras peton, la kaplinio "If-Modified-Since" estas uzata por kontroli ĉu la rimedo estis modifita.
305 Uzi Prokurilon. Kiel respondon, la servilo raportas, ke ĝi uzu la specifitan prokurilon por aliri la petitan rimedon.
306 (rezervita) — La kodo estas rezervita, sed fakte ĝi ne estas uzata.
307 Provizora Alidirektado . Ĉi tiu kodo similas al 302 Trovita, sed postulas, ke la kliento restu en la petmetodo uzita en la originala peto.
308 Daŭra Alidirektado . Indikas, ke la rimedo faris daŭran translokiĝon al nova URI kaj la kliento uzu la novan URI por ĉiuj estontaj petoj.
4xx HTTP-Eraro (Klienta eraroj)
HTTP 4xx-eraraj kodoj indikas klientajn erarojn. Ĉi tio signifas, ke la problemo estas ĉe la uzanto-flanko, kiel la retumilo aŭ programo.
400 Malbona Peto . La servilo ne povas prilabori la peton pro sintaksaj eraroj, malvalidaj datumoj aŭ aliaj eraroj ĉe la klienta flanko.
401 Neaŭtorizita. La servilo ne povas prilabori la peton pro sintaksaj eraroj, malvalidaj datumoj aŭ aliaj eraroj ĉe la klienta flanko.
402 Pago Necesa . La kodo ne estas aktiva nuntempe kaj estas rezervita por estonta uzo. Ĝi eble indikas la bezonon pagi antaŭ ol aliri la rimedon estonte.
HTTP-eraro 403 Malpermesita. La kliento ne havas sufiĉajn rajtojn por aliri la petitan rimedon.
404 Ne trovita. La petita rimedo ne ekzistas sur la servilo. Ĉi tio estas unu el la plej oftaj uzantaj eraroj.
405 Metodo Ne Permesita . La servilo ne subtenas la specifitan petmetodon en ĉi tiu rimedo. La titolo "Permesi" indikas la permesitajn metodojn por la rimedo. Kun ĉi tiu kodo,
406 Ne Akceptebla. La servilo ne povas provizi datumojn en formato akceptebla de la kliento.
407 Prokurila Aŭtentigo Necesas . Aŭtentigo ĉe prokurila servilo estas necesa por aliri la petitan rimedon.
408 Peto-Tempolimo . La servilo atendis por ricevi peton de la kliento, sed ĝi tempolimis. La kaplinio "Retry-After" eble indikas la tempon post kiu la peto povas esti reprovita.
409 Konflikto. La peto ne povas esti kompletigita pro konflikto kun la nuna stato de la rimedo.
410 For . La petita rimedo antaŭe ekzistis sed nun estas forigita kaj ĝia restarigo ne estas atendata.
411 Bezonata longo . La servilo postulas specifi la longon de la enhavo en la peto; la manko de ĉi tiu informo estas konsiderata eraro.
412 Antaŭkondiĉo Malsukcesis . Antaŭkondiĉo en la peto ne estas plenumita, kio malhelpas ĝian plenumon.
413 Tro Granda Ŝarĝo . La grandeco de la petaj datumoj superas la servilajn limojn.
414 URI Tro Longa . La URI-longo en la peto superas akcepteblajn limojn.
415 Nesubtenata Datumtipo . La servilo ne povas prilabori la datumtipon donitan en la peto.
416 Intervalo Ne Kontentigebla . HTTP-eraro kie la petita intervalo ne kongruas kun la nunaj servilaj datumoj.
417 Atendado Malsukcesis . La atendata kondiĉo en la "Atendi" kaplinio ne estis plenumita.
418 Mi estas tekruĉo . Ĉi tiu kodo estas inkluzivita kiel ŝerco kaj ne implicas ian ajn realan agon por la uzanto aŭ servilo, kaj ne estas plenkreska eraro. Ĝi indikas, ke la servilo estas tekruĉo kaj ne kapablas fari kafon.
421 Misdirektita Peto . La servilo ne prilaboras la peton pro eraro en la peto aŭ servila agordo.
422 Neprilaborebla Ento . La servilo komprenas la peton, sed ne prilaboras ĝin pro dateneraroj.
423 Ŝlosita. La rimedo estas blokita kaj ne povas esti prilaborita.
424 Malsukcesa Dependeco . La peto dependas de alia neplenumita peto.
425 Tro Frue. La servilo ne pretas prilabori la peton pro ĝia frua alveno.
426 Ĝisdatigo Necesa . La servilo postulas la uzon de pli progresinta protokolo por prilabori la peton.
428 Antaŭkondiĉo Bezonata . La servilo postulas, ke certaj antaŭkondiĉoj estu specifitaj en la peto.
429 Tro Multaj Petoj . La kliento sendis tro multajn petojn en mallonga tempo, superante la limojn de la servilo.
431 Kampoj de Peto-Kaplinio Tro Grandaj . La peto-kaplinioj superas la maksimuman permesitan grandecon.
449 Reprovi kun. Indikas, ke la peto ne povas esti plenumita de la nuna servilo, sed povas esti sukcese prilaborita de alia servilo, kaj la kliento devas reprovi la peton kun nova URI.
451 Nedisponebla pro juraj kialoj . La rimedo ne haveblas pro juraj kialoj.
499 Kliento Fermita Peto . La servilo ricevis la peton, sed la konekto estis fermita de la kliento antaŭ ol la prilaborado finiĝis.
HTTP 5xx-eraro (servilaj eraroj)
HTTP 5xx-eraraj kodoj indikas la servilproblemojn. Ĉi tiuj kodoj indikas problemojn kiuj okazis ĉe la servilo, igante la servilon nekapabla trakti la peton de la uzanto en ĝusta maniero. Ni rigardu ilin pli detale:
HTTP-eraro 500 Interna servila eraro . La servilo renkontas neatenditajn cirkonstancojn, kiuj malhelpas ĝin plenumi la peton. La kaplinio "Servilo" povas indiki la servilon, sur kiu la eraro okazis.
501 Ne efektivigita . La servilo ne subtenas la funkciojn bezonatajn por prilabori la peton de la kliento. La kaplinio "Via" eble indikas la prokurilon per kiu la eraro okazis.
502 Malbona Enirejo . Ĉi tiu kodo signifas, ke la servilo, kiu agas kiel prokurilo, ricevis malĝustan respondon de alia servilo.
HTTP- eraro 503 Servo nedisponebla . La servilo provizore ne kapablas prilabori petojn.
504 Enireja Taŭgeco . La servilo, kiu agas kiel prokurilo, ne ricevis ĝustatempan respondon de alia servilo.
505 HTTP-Versio Ne Subtenata . La servilo ne subtenas la HTTP-protokolan version specifitan en la peto. Kiel rezerva opcio, la kaplinio "Ĝisdatigo" povas indiki subtenatajn protokolojn.
506 Varianto Ankaŭ Negocas . Ĉi tiu stato ne estas uzata en HTTP/1.1; tamen, se la servilo detektas internan agordon, kiu rezultigas ambiguecon pri enhava intertraktado, ĝi povas uzi ĉi tiun respondon.
507 Nesufiĉa stokado . La servilo ne povas plenumi la peton pro nesufiĉa stokadospaco sur la servilo.
508 Buklo Detektita . La servilo detektis buklon dum prilaborado de la peto, kaj rifuzas kompletigi la peton por eviti senfinan buklon.
509 Limo de Bendlarĝo Superita . La eraro okazas kiam la bendlarĝo de la servilo estas superita pro granda kvanto da petoj aŭ trafiko.
510 Ne Plilongigita . La kliento devas transdoni pliajn plilongigojn por daŭrigi la peton.
511 Reta Aŭtentigo Necesa . La kliento devas aŭtentigi sin por akiri aliron al la reto.
Kiel kontroli la paĝan statuskodon
En ĉi tiu sekcio, ni konsideros tri ĉefajn manierojn kontroli la paĝan statuskodon: per la komandlinio, uzante retumilon kaj uzante sendependajn retajn servojn. Ĉiu el ĉi tiuj metodoj havas siajn proprajn avantaĝojn kaj povas esti utila en malsamaj situacioj.
Kontrolante servilan respondon per komandlinio
La komandlinio provizas oportunan manieron kontroli la paĝan statuskodon sen devi uzi retumilon. Por ĉi tiu metodo, vi devas malfermi la komandlinion kaj uzi la komandon:
curl -I http://page-addressĈi tiu komando sendas HEAD-peton (nur kaplinioj) al la specifita URL kaj montras informojn inkluzive de la HTTP-statuskodo:
La supra ekzemplo montras sukcesan respondkodon. En la kazo de respondo kiu enhavas erarkodon, kiel ekzemple 404 Not Found HTTP-eraro, la rezulto aspektos simila:
Kontrolante la servilan respondon per la retumila konzolo
La retumila programkonzolo disponigas ilojn por fari diversajn operaciojn, inkluzive de kontrolado de la paĝa statuskodo. Por vidi la HTTP-kodon en la servila respondo, vi devas malfermi la programkonzolon (Ctrl+Shift+K) aŭ (Ctrl+shift+J) depende de la retumilo uzata. Poste, elektu la sekcion "reto" kaj ŝarĝu la deziratan paĝon:
Kontrolante la servilan respondon uzante sendependajn ilojn
Ekzistas granda nombro da sendependaj interretaj servoj, kiuj provizas ilojn por kontroli la statuskodon de la retpaĝo. Ĉi tiuj servoj kutime permesas al vi rapide ricevi superrigardon pri la havebleco kaj rendimento de via rimedo. Ili ĉiuj funkcias laŭ la sama principo. Ekzemple, ni konsideros la plej popularan rimedon - httpsstatus.io.
Antaŭ ĉio, vi devas malfermi la servon mem, poste enigi la adreson de la paĝo, kiun vi bezonas ekscii respondon, kaj peti konfirmon:
La rezulto estos montrata malsupre de la paĝo:
konkludo
Konklude, oni devas emfazi, ke kompreni kaj povi legi HTTP-erarkodojn estas ŝlosila lerteco por iu ajn implikita en retejo-disvolviĝo kaj prizorgado de servilo. Dum ni eltrovas ĉiun eraron kaj esploras la ilojn por detekti ilin, ni vidas kialojn, kial estas tiel grave efike administri ĉi tiujn aspektojn de retservoj.
