Hoekom een prent misluk terwyl die res van die bladsy laai
Drie toestande skei ’n netwerkfout van ’n geblokkeerde versoek en ’n weergefout. Vind die URL wat die blaaier gekies het voordat jy die pad verander.
Die bladsy laai, die teks verskyn, en een prent is ’n gebreekte ikoon. Die eerste reaksie is om die tonnel te blameer, want die tonnel is die ding wat verander het. Voordat jy dit doen, vind uit watter URL die blaaier werklik vir daardie prent aangevra het, want die bladsy-URL en die prent-URL is twee verskillende stukke bewyse. Die meeste verslae oor ontbrekende prente lei na ’n gasheer wat nooit ’n werkende versoek gekry het nie, en daardie antwoord kos net een kyk na die Netwerk-paneel.
Drie toestande bepaal waar jy moet kyk
Die eerste toestand is of die prent van dieselfde gasheer as die bladsy kom. ’n Aparte prent-gasheer het sy eie naamresolusie, sy eie verbinding en sy eie TLS-identiteit nodig, so ’n bladsy wat laai sê niks daaroor nie.
Die tweede is of die blaaier die versoek geblokkeer het voordat dit gestuur is. Gemengde inhoud, inhoudsveiligheidsbeleid en verwysingsreëls kan ’n prent stop sonder om ’n gewone bedienerantwoord te lewer, daarom verskyn daar geen mislukte versoek in die lys nie.
Die derde is of die lewering geslaag het en die weergawe gefaal het — ’n geval waar die grepe aankom en die prent steeds nie verskyn nie. Daardie drie toestande het drie verskillende eienaars, en net die eerste een is ’n netwerkvraag.
| 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 |
Vind die hulpbron wat die blaaier werklik gekies het
Die URL wat jy in die bladsybron sien, is dikwels nie die URL wat aangevra is nie. Bronsstelle, prent-elemente en CSS-agtergronde laat almal die blaaier toe om ’n ander hulpbron te kies op grond van sienvensterwydte, pikseldigtheid of formaatondersteuning. ’n Lui-gelaaide prent word dalk glad nie aangevra voordat die bladsy ’n bepaalde toestand bereik nie.
Ondersoek die element en die versoek saam, en hou die inisieerder by die versoek wanneer jy die probleem rapporteer. MDN se verwysing vir die prent-element dek bronskeuse, laaigedrag en verwysingsbeheer op een plek, wat genoeg is om te sien watter kenmerk die foutende URL gekies het.
Teken die gasheernaam, die status, enige herleidingsketting en die antwoord se inhoudstipe aan. ’n 200 wat ’n aanmeldbladsy terugstuur, is nie ’n bruikbare prent nie, en ’n herleiding na ’n HTML-foutbladsy lyk dieselfde as ’n gebreekte lêer totdat jy die tipe lees.
Lees die status voordat jy na die netwerk kyk
’n Tydverstreke versoek, ’n geweierde versoek en ’n dekoderingsfout vra verskillende volgende stappe, en die statuskode is wat hulle skei. ’n Tydverstreke versoek wys na resolusie, roete of ’n gasheer wat nie antwoord nie. ’n Geweierde versoek wys na ’n beleid of ’n magtigingslaag. ’n Dekoderingsfout wys na die grepe of die formaat.
As die versoek glad nie verskyn nie, hou op om na die netwerk te kyk en kyk na die opmaak. Die algemeenste oorsaak is ’n bronsstel-inskrywing wat die blaaier verkies het en wat nie meer op die bediener bestaan nie, gevolg deur ’n element wat ’n script nooit sigbaar gemaak het nie.
Daardie onderskeid alleen voorkom die meeste vermorsde moeite in hierdie klas verslae.
Wanneer die blaaier dit blokkeer, is daar geen antwoord om te lees nie
Gemengde inhoud is die klassieke geval: ’n HTTPS-bladsy wat ’n prent oor gewone HTTP aanvra, kry die versoek geblokkeer eerder as gefaal, en die konsole teken die rede aan. Inhoudsveiligheidsbeleid lewer dieselfde vorm, met die geblokkeerde riglyn in die boodskap genoem. ’n Verwysingsbeleid wat die kop stroop, kan ook veroorsaak dat ’n gasheer met hotlink-beskerming ’n plekhouer in plaas van die prent terugstuur.
Lees die aangetekende rede voordat jy aan die netwerkpad raak, want hierdie blokke verbeter nie wanneer die roete verander nie. Om kruis-oorsprong-toestemmings by te voeg is ook nie die oplossing nie: om ’n prent van ’n ander gasheer te wys en om sy pixels in ’n canvas te lees, is verskillende bewerkings, en net die tweede een het die kopreëls nodig wat mense inplak.
Vir ’n werf wat jy administreer, korrigeer die hulpbron-URL, die antwoord of die beleid by sy eienaar en hou die magtiging- en verwysingsvereistes ongeskonde. Vir ’n werf wat jy nie beheer nie, stuur die bladsy en versoekbewyse na sy ondersteuningskanaal in plaas daarvan om private of vervallende hulpbron-skakels weer te publiseer.
Vergelyk paaie sonder om die bewyse te verander
As jy wel die toegangspad wil toets, hou alles anders konstant: dieselfde bladsy, dieselfde rekening, dieselfde gekose prent, een toegelate pad verander. Vergelyk die versoekinskrywings langs mekaar eerder as die weergegewe resultaat, want die weergegewe resultaat sê vir jou of die prent verskyn het, nie hoekom nie.
’n Prent wat op ’n nuwe roete laai, bewys nie dat daardie roete gemagtig is nie, en ’n prent wat gebreek bly, bewys nie dat die tonnel skuld het nie. As die prent verwyder is of toegang doelbewus beperk is, gebruik ’n ondersteunde alternatief eerder as om sertifikaatkontroles uit te skakel of iemand anders se beskermde materiaal te spieël.
Werkorde: identifiseer die gekose URL, lees sy status en tipe, kyk of daar ’n aangetekende blokrede is, en vergelyk dan een padverandering op ’n slag.