Siden lastes, teksten vises, og ett bilde blir et ødelagt ikon. Den første reaksjonen er å skylde på tunnelen, fordi tunnelen er det som ble endret. Før det, finn ut hvilken URL nettleseren faktisk ba om for det bildet, fordi sidens URL og bildets URL er to forskjellige bevis. De fleste rapporter om manglende bilder ender hos en vert som aldri fikk en fungerende forespørsel, og det svaret koster ett blikk på panelet Nettverk.

Tre forhold avgjør hvor du skal lete

Det første forholdet er om bildet kommer fra samme vert som siden. En egen bildevert trenger sin egen navneoppslag, sin egen tilkobling og sin egen TLS-identitet, så en side som lastes sier ingenting om den.

Det andre er om nettleseren blokkerte forespørselen før den ble sendt. Blandet innhold, innholdssikkerhetspolicy og referrer-regler kan stoppe et bilde uten å produsere et vanlig serversvar, derfor vises ingen mislykket forespørsel i listen.

Det tredje er om leveringen lyktes og visningen feilet, et tilfelle der bytene ankommer og bildet likevel ikke vises. Disse tre forholdene har tre forskjellige eiere, og bare det første er et nettverksspørsmål.

What you seeWhere the fault sits
Request absent from the listMarkup, lazy loading or a policy that blocked it
Request failed or timed outResolution, route, TLS or the image host itself
Request returned 200, image blankResponse type, decoding or rendering

Finn ressursen nettleseren faktisk valgte

URL-en du ser i sidens kildekode er ofte ikke URL-en som ble forespurt. Kildesett, picture-elementer og CSS-bakgrunner lar alle nettleseren velge en annen ressurs basert på visningsbredde, pikseltetthet eller formatstøtte. Et late-lastet bilde blir kanskje ikke forespurt i det hele tatt før siden når en bestemt tilstand.

Undersøk elementet og forespørselen sammen, og behold initiativtakeren sammen med forespørselen når du rapporterer problemet. MDNs referanse for bildeelementet dekker kildevalg, lasteatferd og referrer-kontroller på ett sted, noe som er nok til å avgjøre hvilken attributt som valgte den feilende URL-en.

Noter vertsnavnet, statusen, en eventuell omdirigeringskjede og svarets innholdstype. Et 200 som returnerer en påloggingsside er ikke et brukbart bilde, og en omdirigering til en HTML-feilside ser identisk ut med en ødelagt fil til du leser typen.

Les statusen før nettverket

Tidsavbrudd, en avvist forespørsel og en dekodingsfeil krever forskjellige neste steg, og statuskoden er det som skiller dem. Et tidsavbrudd peker på navneoppslag, rute eller en vert som ikke svarer. En avvist forespørsel peker på en policy eller et autorisasjonslag. En dekodingsfeil peker på bytene eller formatet.

Hvis forespørselen ikke vises i det hele tatt, slutt å se på nettverket og se på markupen. Den vanligste årsaken er en oppføring i et kildesett som nettleseren foretrakk og som ikke lenger finnes på serveren, etterfulgt av et element som et skript aldri gjorde synlig.

Nettopp denne forskjellen hindrer mesteparten av bortkastet arbeid i denne typen rapporter.

Når nettleseren blokkerer det, er det ingen respons å lese

Blandet innhold er det klassiske tilfellet: en HTTPS-side som ber om et bilde over vanlig HTTP får forespørselen blokkert i stedet for mislykket, og konsollen registrerer årsaken. Innholdssikkerhetspolicy gir samme form, med den blokkerte direktivet navngitt i meldingen. En referrer-policy som fjerner headeren kan også få en hotlink-beskyttet vert til å returnere en plassholder i stedet for bildet.

Les den registrerte årsaken før du rører nettverksstien, fordi disse blokkeringene ikke blir bedre når ruten endres. Det er heller ikke løsningen å legge til cross-origin-tillatelser: å vise et bilde fra en annen vert og å lese pikslene i et canvas er forskjellige operasjoner, og bare den andre trenger headerne folk limer inn.

For et nettsted du administrerer, rett ressurs-URL-en, svaret eller policyen hos eieren og hold autorisasjons- og referrer-kravene intakte. For et nettsted du ikke kontrollerer, send siden og forespørselsbevisene til støttekanalen i stedet for å publisere private eller utløpende ressurslenker på nytt.

Sammenlign stier uten å endre bevisene

Hvis du vil teste tilgangsstien, hold alt annet konstant: samme side, samme konto, samme valgte bilde, én tillatt sti endret. Sammenlign forespørselsoppføringene side ved side i stedet for det viste resultatet, fordi det viste resultatet sier om bildet dukket opp, ikke hvorfor.

Et bilde som lastes på en ny rute beviser ikke at ruten er autorisert, og et bilde som forblir ødelagt beviser ikke at tunnelen er skyld i det. Hvis bildet er fjernet eller tilgangen er bevisst begrenset, bruk et støttet alternativ i stedet for å slå av sertifikatkontroller eller speile andres beskyttede materiale.

Arbeidsrekkefølge: identifiser den valgte URL-en, les statusen og typen, sjekk om det finnes en registrert blokkeringsårsak, og sammenlign deretter én stiendring om gangen.

Relaterte artikler