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ŭrigi. HTTP respondkodo en kiu la servilo donas la verdan lumon al la uzanto, permesante al li sekure daŭrigi sendi grandan peton.
101 Ŝaltaj Protokoloj. La servilo diras al la kliento, 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 "Ĝisdatigi" estas uzata por la protokoloŝanĝo.
102 Prilaborado. Ĉi tiu kodo estas kiel mesaĝo, ke la servilo akceptis la peton, sed ankoraŭ estas okupata de kompleksa operacio.
103 Fruaj Sugestoj. Ĉi tie la servilo sendas plurajn indikajn kapliniojn al la kliento antaŭ la ĉefa respondo, avertante pri io, kio povas 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 statuso estas uzata kiam la servilo prilaboras peton per GET-metodo sen problemoj kaj resendas la petitajn datumojn en respondo. La kaplinio "Enhavo-Tipo" raportas la enhavspecon en la respondo. Ĝi nur informas la klienton, ke la peto sukcesis.
201 Kreita. Ĉi tie la servilo anoncas la kreadon de nova rimedo.
202 Akceptite. La servilo sciigas al la uzanto ke la peto estis 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 resendas aldonan enhavon.
205 Restarigi Enhavon. Ĉi tie la kliento estas instrukciita restarigi la nunan vidon aŭ datumojn post sendo.
206 Parta Enhavo. Ĉi tiu kazo indikas, ke la respondo enhavas nur parton de la petita enhavo. La kaplinio "Enhavo-Range" indikas la partan enhavon.
207 Multi-Stato. La servilo sukcese plenumis mult-operacian 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 de Krementaj Metadatumoj (IM) kaj respondis pasigante nur la modifitajn rimedpartojn 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 respondo. En nunaj cirkonstancoj, la kaplinio "Loko" povas indiki alternativajn elektojn por la rimedo.
301 Movita Konstante. La servilo raportas al la uzanto, ke la rimedo estas konstante movita al alia loko.
302 Trovita. Ĉi tiu HTTP-kodo similas al provizora alidirektilo. La servilo informas la konsumanton ke la rimedo estas provizore havebla ĉe malsama URL. La kaplinio "Loko" montras la novan URL por la provizora alidirektilo.
303 Vidu Aliaj. Oni diras al la kliento, ke la rimedo disponeblas ĉe malsama URL kaj devas fari GET-peton al ĉi tiu nova adreso.
304 Ne Modifita. Ĉi tiu stato diras al la kliento, ke la rimedo restis senŝanĝa ekde la lasta peto kaj ne bezonas esti elŝutita denove. Dum peto, la kaplinio "If-Modified-Since" estas uzata por kontroli ĉu la rimedo estas modifita.
305 Uzu Prokurilon. Kiel respondo, la servilo raportas, ke ĝi devus uzi la specifitan prokurilon por aliri la petitan rimedon.
306 (rezervita) — La kodo estas rezervita, sed fakte ĝi ne estas uzata.
307 Provizora Redirekto. Ĉi tiu kodo similas al 302 Trovita, sed postulas, ke la kliento restu en la peta metodo, kiu estis uzata en la originala peto.
308 Konstantaj Redirektoj. Indikas ke la rimedo faris konstantan movon al nova URI kaj la kliento devus uzi 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 procesi la peton pro sintaksaj eraroj, nevalidaj datumoj aŭ aliaj eraroj ĉe la kliento.
401 Neaŭtorizita. La servilo ne povas procesi la peton pro sintaksaj eraroj, nevalidaj datumoj aŭ aliaj eraroj ĉe la kliento.
402 pago bezonata. La kodo ne aktivas nuntempe kaj estas rezervita por estonta uzo. Ĝi povas indiki la bezonon pagi antaŭ aliri la rimedon en la estonteco.
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 tiu estas unu el la plej oftaj eraroj de uzantoj.
405-Metodo Ne Permesita. La servilo ne subtenas la specifitan petan metodon dum ĉi tiu rimedo. La kaplinio "Permesi" indikas la permesitajn metodojn por la rimedo. Kun ĉi tiu kodo,
406 Ne Akceptebla. La servilo ne povas provizi datumojn en formato kiu povas esti akceptita de la kliento.
407 Prokura Aŭtentigo Bezonata. Aŭtentigo sur prokura servilo estas postulata por aliro al la petita rimedo.
408 Peto-Tempo. La servilo atendis ricevi peton de la kliento, sed elĉerpiĝis. La kaplinio "Retry-After" povas indiki la tempon post kiu la peto povas esti reprovita.
409 Konflikto. La peto ne povas esti plenumita pro konflikto kun la nuna rimedstato.
410 Foriris. La petita rimedo antaŭe ekzistis sed nun estis forigita kaj ĝia restarigo ne estas atendita.
411 Longo Bezonata. La servilo postulas specifi la enhavlongon en la peto; la foresto de ĉi tiu informo estas konsiderata eraro.
412 Antaŭkondiĉo malsukcesis. Antaŭkondiĉo en la peto ne estas plenumita, tio malhelpas ĝin ekzekuti.
413 Utila Ŝarĝo Tro Granda. La grandeco de la petaj datumoj superas la servillimojn.
414 URI Tro Longa. URI-longo en la peto superas akcepteblajn limojn.
415 Nesubtenata Duona Tipo. La servilo ne povas prilabori la datumtipo provizitan en la peto.
416 Gamo Ne Kontentebla. HTTP-eraro kie la petita intervalo ne kongruas kun la nunaj servilaj datumoj.
417 Atendoj Malsukcesis. La atendata kondiĉo en la kaplinio "Atendu" ne estis plenumita.
418 Mi estas tekruĉo. Ĉi tiu kodo estas inkluzivita kiel ŝerco kaj ne implicas ajnan realan agon por la uzanto aŭ servilo, kaj ne estas plentaŭga eraro. Ĝi indikas, ke la servilo estas tekruĉo kaj ne kapablas fari kafon.
421 Misdirektita Peto. La servilo ne procesas la peton pro eraro en la peto aŭ servila agordo.
422 Neprocesebla Ento. La servilo komprenas la peton, sed ne prilaboras ĝin pro datumaj eraroj.
423 Ŝlosita. La rimedo estas blokita kaj ne povas esti procesita.
424 Malsukcesa Dependeco. La peto dependas de alia nefarita peto.
425 Tro Frue. La servilo ne pretas prilabori la peton pro ĝia frua alveno.
426 Ĝisdatigo Bezonata. La servilo postulas la uzon de pli altnivela protokolo por procesi la peton.
428 Antaŭkondiĉo Bezonata. La servilo postulas certajn antaŭkondiĉojn esti specifitaj en la peto.
429 Tro da Petoj. La kliento sendis tro multajn petojn en mallonga tempo, superante la limojn de la servilo.
431 Peto Header Kampoj Tro Grandaj. Petaj kaplinioj superas la maksimuman permesitan grandecon.
449 Reprovu kun. Indikas ke la peto ne povas esti rulita de la nuna servilo, sed povas esti sukcese procesita de alia servilo, kaj la kliento devus reprovi la peton kun nova URI.
451 Nedisponebla pro Juraj Kialoj. La rimedo estas neatingebla pro juraj kialoj.
499 Kliento Fermita Peto. La servilo ricevis la peton, sed la konekto estis fermita de la kliento antaŭ pretigado.
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 de la petokompletigo La "Servilo" kaplinio povas indiki la servilon sur kiu la eraro okazis.
501 Ne Efektivigita. La servilo ne subtenas la funkciojn necesajn por procesi la peton de la kliento. La kaplinio "Per" povas indiki la prokuran servilon per kiu la eraro okazis.
502 Malbona Pordejo. Ĉi tiu kodo signifas, ke la servilo, kiu funkcias kiel prokurilo, ricevis malĝustan respondon de alia servilo.
HTTP eraro 503-servo Nombro. La servilo provizore ne povas procesi petojn.
504 Pordega Elpensado. La servilo, kiu funkcias kiel prokurilo, ne ricevis ĝustatempan respondon de alia servilo.
505 HTTP-Versio Ne Elportita. La servilo ne subtenas la HTTP-protokolo-version specifitan en la peto. Kiel rezerva opcio, la kaplinio "Ĝisdatigi" povas indiki subtenatajn protokolojn.
506 Variaĵo Ankaŭ Negocas. Ĉi tiu stato ne estas uzata en HTTP/1.1; tamen, se la servilo detektas internan agordon kiu rezultigas enhavintertraktadon ambiguecon, ĝi povas uzi ĉi tiun respondon.
507 Nesufiĉa Stokado. La servilo ne povas plenumi la peton pro nesufiĉa konserva spaco sur la servilo.
508 Buklo Detektita. La servilo detektis buklon prilaborante la peton, kaj rifuzas kompletigi la peton por eviti senfinan buklon.
509 Bandwidth Limit Exceeded. La eraro okazas kiam la bendolarĝo de la servilo estas superita pro alta volumo de petoj aŭ trafiko.
510 Ne Etendita. La kliento devas transdoni pliajn etendaĵojn por daŭrigi la peton.
511 Reta Aŭtentigo Bezonata. La kliento devas aŭtentikigi 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
Estas granda nombro da sendependaj interretaj servoj, kiuj provizas ilojn por kontroli la statuskodon de la retejo. Ĉi tiuj servoj kutime permesas al vi rapide ricevi superrigardon pri la havebleco kaj rendimento de via rimedo. Ili ĉiuj funkcias uzante la saman principon. Ekzemple, ni konsideros la plej popularan rimedon - httpstatus.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.
