Hvorfor ét billede fejler, mens resten af siden indlæses

Siden indlæses, teksten vises, og ét billede er et ødelagt ikon. Den første reaktion er at give tunnelen skylden, fordi tunnelen er det, der blev ændret. Før du gør det, skal du finde ud af, hvilken URL browseren faktisk anmodede om for det billede, fordi sidens URL og billedets URL er to forskellige beviser. De fleste rapporter om manglende billeder ender hos en vært, der aldrig fik en fungerende anmodning, og det svar koster kun et blik på panelet Netværk.

Tre betingelser afgør, hvor du skal lede

Den første betingelse er, om billedet kommer fra samme vært som siden. En separat billedvært har brug for sit eget navneopslag, sin egen forbindelse og sin egen TLS-identitet, så en side, der indlæses, siger intet om den.

Den anden er, om browseren blokerede anmodningen, før den blev sendt. Blandet indhold, indholdssikkerhedspolitik og referrer-regler kan stoppe et billede uden at producere et almindeligt serversvar, og derfor vises ingen mislykket anmodning i listen.

Den tredje er, om leveringen lykkedes, men visningen fejlede — et tilfælde, hvor byte ankommer, og billedet stadig ikke vises. De tre betingelser har tre forskellige ejere, og kun den første er et netværksspørgsmål.

Find den ressource, browseren faktisk valgte

Den URL, du ser i sidens kildekode, er ofte ikke den URL, der blev anmodet om. Kildesæt, picture-elementer og CSS-baggrunde lader alle browseren vælge en anden ressource ud fra visningsbredde, pixeltæthed eller formatunderstøttelse. Et dovent indlæst billede bliver måske slet ikke anmodet om, før siden når en bestemt tilstand.

Undersøg elementet og anmodningen sammen, og behold initiativtageren sammen med anmodningen, når du rapporterer problemet. MDN's reference for billedelementet dækker kildevalg, indlæsningsadfærd og referrer-kontroller på ét sted, hvilket er nok til at afgøre, hvilken attribut der valgte den fejlende URL.

Notér værtsnavnet, status, eventuelle omdirigeringskæde og svarets indholdstype. Et 200, der returnerer en login-side, er ikke et brugbart billede, og en omdirigering til en HTML-fejlside ser identisk ud med en ødelagt fil, indtil du læser typen.

Læs status før netværket

Timeout, en afvist anmodning og en afkodningsfejl kræver forskellige næste skridt, og statuskoden er det, der skiller dem. En timeout peger på navneopslag, rute eller en vært, der ikke svarer. En afvist anmodning peger på en politik eller et autoriseringslag. En afkodningsfejl peger på byte eller format.

Hvis anmodningen slet ikke vises, så hold op med at kigge på netværket og se på markupen. Den mest almindelige årsag er en post i et kildesæt, som browseren foretrak, og som ikke længere findes på serveren, efterfulgt af et element, som et script aldrig gjorde synligt.

Netop den sondring forhindrer det meste spildte arbejde i denne type rapporter.

Når browseren blokerer det, er der intet svar at læse

Blandet indhold er det klassiske tilfælde: en HTTPS-side, der anmoder om et billede over almindelig HTTP, får anmodningen blokeret i stedet for mislykket, og konsollen registrerer årsagen. Indholdssikkerhedspolitik giver samme form, med den blokerede direktiv nævnt i meddelelsen. En referrer-politik, der fjerner headeren, kan også få en hotlink-beskyttet vært til at returnere en pladsholder i stedet for billedet.

Læs den registrerede årsag, før du rører netværksstien, fordi disse blokeringer ikke bliver bedre, når ruten ændres. Det er heller ikke løsningen at tilføje cross-origin-tilladelser: at vise et billede fra en anden vært og at læse dets pixels i et canvas er forskellige handlinger, og kun den anden har brug for de headere, folk indsætter.

For et websted, du administrerer, skal du rette ressource-URL'en, svaret eller politikken hos dens ejer og holde autorisations- og referrer-kravene intakte. For et websted, du ikke kontrollerer, skal du sende siden og anmodningsbeviserne til dets supportkanal i stedet for at genudgive private eller udløbende ressourcelinks.

Sammenlign stier uden at ændre beviserne

Hvis du vil teste adgangsstien, skal du holde alt andet konstant: samme side, samme konto, samme valgte billede, én tilladt sti ændret. Sammenlign anmodningsposterne side om side i stedet for det viste resultat, fordi det viste resultat fortæller, om billedet dukkede op, ikke hvorfor.

Et billede, der indlæses på en ny rute, beviser ikke, at ruten er autoriseret, og et billede, der forbliver ødelagt, beviser ikke, at tunnelen er skyld i det. Hvis billedet er blevet fjernet, eller adgangen er bevidst begrænset, skal du bruge et understøttet alternativ i stedet for at deaktivere certifikatkontroller eller spejle andres beskyttede materiale.

Arbejdsrækkefølge: identificer den valgte URL, læs dens status og type, kontroller for en registreret blokeringsårsag, og sammenlign derefter én stiændring ad gangen.