Miks üks pilt ebaõnnestub, kui ülejäänud leht laaditakse
Kolm tingimust eristavad võrgu tõrget blokeeritud päringust ja renderdusveast. Leidke URL, mille brauser valis, enne kui muudate teed.
Leht laaditakse, tekst kuvatakse ja üks pilt jääb katkiseks ikooniks. Esimene reaktsioon on süüdistada tunnelit, sest tunnel on see, mis muutus. Enne seda tehke kindlaks, millist URL-i brauser selle pildi jaoks tegelikult küsis, sest lehe URL ja pildi URL on kaks erinevat tõendit. Enamik puuduva pildi teateid taandub hostile, mis ei saanud kunagi töötavat päringut, ja see vastus maksab ühe pilgu võrgu paneelile.
Kolm tingimust otsustavad, kuhu vaadata
Esimene tingimus on, kas pilt tuleb samalt hostilt kui leht. Eraldi pildihost vajab oma nimeotsingut, oma ühendust ja oma TLS-identiteeti, seega laaditav leht ei ütle selle kohta midagi.
Teine on, kas brauser blokeeris päringu enne selle saatmist. Segasisu, sisuturvapoliitika ja referrer-reeglid võivad pildi peatada ilma tavalise serverivastuseta, seetõttu ei ilmu nimekirja ükski ebaõnnestunud päring.
Kolmas on, kas kohaletoimetamine õnnestus ja renderdus ebaõnnestus — juhtum, kus baidid saabuvad ja pilt ikkagi ei ilmu. Need kolm tingimust on kolme eri omanikuga ja ainult esimene on võrgu küsimus.
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
Leidke ressurss, mille brauser tegelikult valis
URL, mida näete lehe lähtekoodis, ei ole sageli see URL, mida küsiti. Allikakomplektid, picture-elemendid ja CSS-i taustad lubavad brauseril valida teistsuguse ressursi vaateava laiuse, pikslitiheduse või vormingu toe põhjal. Laisalt laaditavat pilti ei pruugita üldse küsida, kuni leht jõuab teatud olekusse.
Uurige elementi ja päringut koos ning hoidke algataja päringu juures, kui probleemist teatate. MDN-i pildielemendi viide katab allikavaliku, laadimiskäitumise ja referrer-kontrollid ühes kohas, millest piisab, et teada saada, milline atribuut valis ebaõnnestunud URL-i.
Pange kirja hostinimi, olek, võimalik ümbersuunamisahel ja vastuse sisutüüp. 200, mis tagastab sisselogimislehe, ei ole kasutatav pilt, ja ümbersuunamine HTML-vigalehele näeb välja identne katkise failiga, kuni tüübi läbi loete.
Lugege olekut enne võrku
Aegumine, keeldutud päring ja dekodeerimisviga vajavad erinevaid järgmisi samme ning olekukood on see, mis need eraldab. Aegumine viitab nimeotsingule, marsruudile või hostile, mis ei vasta. Keeldutud päring viitab poliitikale või autoriseerimiskihile. Dekodeerimisviga viitab baitidele või vormingule.
Kui päringut üldse ei ilmu, lõpetage võrgu vaatamine ja vaadake märgistust. Kõige tavalisem põhjus on allikakomplekti kirje, mille brauser eelistas ja mida serveris enam ei ole, millele järgneb element, mille skript kunagi nähtavaks ei teinud.
Ainuüksi see eristus hoiab ära suurema osa raisatud tööst seda tüüpi teadetes.
Kui brauser selle blokeerib, pole vastust lugeda
Segasisu on klassikaline juhtum: HTTPS-leht, mis küsib pilti tavalise HTTP kaudu, saab päringu blokeerituks, mitte ebaõnnestunuks, ja konsool registreerib põhjuse. Sisuturvapoliitika annab sama kuju, kus blokeeritud direktiiv on sõnumis nimetatud. Referrer-poliitika, mis päise eemaldab, võib samuti panna hotlink-kaitsega hosti tagastama pildi asemel kohatäitja.
Lugege registreeritud põhjust enne võrgutee puudutamist, sest need blokeeringud ei parane marsruudi muutumisel. Ka päritoludevaheliste õiguste lisamine ei ole lahendus: pildi näitamine teiselt hostilt ja selle pikslite lugemine canvasel on erinevad toimingud ning ainult teine vajab päiseid, mida inimesed kleepivad.
Saidil, mida haldate, parandage ressursi URL, vastus või poliitika selle omaniku juures ja hoidke autoriseerimis- ja referrer-nõuded puutumatuna. Saidil, mida te ei kontrolli, saatke leht ja päringu tõendid selle tugikanalisse, selle asemel et avaldada uuesti privaatseid või aeguvaid ressursilinke.
Võrrelge teid tõendeid muutmata
Kui soovite juurdepääsuteed siiski testida, hoidke kõik muu muutumatuna: sama leht, sama konto, sama valitud pilt, üks lubatud tee muudetud. Võrrelge päringukirjeid kõrvuti, mitte renderdatud tulemust, sest renderdatud tulemus ütleb, kas pilt ilmus, mitte miks.
Uuel marsruudil laaditav pilt ei tõesta, et see marsruut on autoriseeritud, ja katkiseks jääv pilt ei tõesta, et tunnel on süüdi. Kui pilt on eemaldatud või juurdepääs on tahtlikult piiratud, kasutage toetatud alternatiivi, selle asemel et sertifikaadikontrolle välja lülitada või kellegi teise kaitstud materjali peegeldada.
Töö järjekord: tuvastage valitud URL, lugege selle olek ja tüüp, kontrollige registreeritud blokeeringu põhjust ja võrrelge seejärel ühte tee muudatust korraga.