Dlaczego jeden obraz nie ładuje się, a reszta strony tak
Trzy warunki oddzielają awarię sieci od zablokowanego żądania i od błędu renderowania. Znajdź adres URL, który wybrała przeglądarka, zanim zmienisz ścieżkę.
Strona się ładuje, tekst jest wyświetlany, a jeden obraz pozostaje złamaną ikoną. Pierwsza reakcja to obwinianie tunelu, bo to tunel się zmienił. Wcześniej ustal, którego adresu URL przeglądarka faktycznie zażądała dla tego obrazu, bo adres strony i adres obrazu to dwa różne dowody. Większość zgłoszeń o brakującym obrazie kończy się na hoście, który nigdy nie otrzymał działającego żądania, a ta odpowiedź kosztuje jedno spojrzenie na panel Sieć.
Trzy warunki decydują, gdzie szukać
Pierwszy warunek to, czy obraz pochodzi z tego samego hosta co strona. Osobny host obrazów potrzebuje własnego rozwiązywania nazw, własnego połączenia i własnej tożsamości TLS, więc strona, która się ładuje, nic o nim nie mówi.
Drugi to, czy przeglądarka zablokowała żądanie przed jego wysłaniem. Mieszana treść, polityka bezpieczeństwa treści i reguły referrera mogą zatrzymać obraz bez zwykłej odpowiedzi serwera, dlatego na liście nie pojawia się żadne nieudane żądanie.
Trzeci to, czy dostarczenie się powiodło, a renderowanie nie, przypadek, w którym bajty docierają, a obraz nadal się nie pojawia. Te trzy warunki mają trzech różnych właścicieli, i tylko pierwszy jest kwestią sieci.
| 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 |
Znajdź zasób, który przeglądarka faktycznie wybrała
Adres URL widoczny w kodzie źródłowym strony często nie jest adresem, którego zażądano. Zestawy źródeł, elementy picture i tła CSS pozwalają przeglądarce wybrać inny zasób na podstawie szerokości okna, gęstości pikseli lub obsługi formatu. Obraz ładowany leniwie może w ogóle nie zostać zażądany, dopóki strona nie osiągnie określonego stanu.
Zbadaj element i żądanie razem, a zgłaszając problem, zachowaj inicjatora przy żądaniu. Dokumentacja elementu obrazu MDN obejmuje wybór źródła, zachowanie ładowania i kontrolę referrera w jednym miejscu, co wystarcza, by stwierdzić, który atrybut wybrał nieudany adres.
Zapisz nazwę hosta, status, ewentualny łańcuch przekierowań i typ treści odpowiedzi. Odpowiedź 200 zwracająca stronę logowania nie jest użytecznym obrazem, a przekierowanie na stronę błędu HTML wygląda tak samo jak uszkodzony plik, dopóki nie odczytasz typu.
Czytaj status przed siecią
Przekroczenie limitu czasu, odrzucone żądanie i błąd dekodowania wymagają różnych kolejnych kroków, a to kod statusu je rozdziela. Przekroczenie limitu czasu wskazuje na rozwiązywanie nazw, trasę lub hosta, który nie odpowiada. Odrzucone żądanie wskazuje na politykę lub warstwę autoryzacji. Błąd dekodowania wskazuje na bajty lub format.
Jeśli żądanie w ogóle się nie pojawia, przestań patrzeć na sieć i spójrz na znaczniki. Najczęstszą przyczyną jest wpis w zestawie źródeł, który przeglądarka preferowała i którego nie ma już na serwerze, a po nim element, którego skrypt nigdy nie uczynił widocznym.
Samo to rozróżnienie zapobiega większości zmarnowanej pracy w tego typu zgłoszeniach.
Gdy przeglądarka blokuje, nie ma odpowiedzi do czytania
Mieszana treść to klasyczny przypadek: strona HTTPS, która prosi o obraz przez zwykły HTTP, dostaje żądanie zablokowane, a nie nieudane, i konsola zapisuje przyczynę. Polityka bezpieczeństwa treści daje ten sam kształt, a zablokowana dyrektywa jest nazwana w komunikacie. Polityka referrera usuwająca nagłówek może też sprawić, że host chroniony przed hotlinkowaniem zwróci atrapę zamiast obrazu.
Przeczytaj zapisaną przyczynę, zanim dotkniesz ścieżki sieciowej, bo te blokady nie poprawiają się przy zmianie trasy. Dodawanie uprawnień cross-origin też nie jest rozwiązaniem: wyświetlanie obrazu z innego hosta i odczytywanie jego pikseli w canvas to różne operacje, i tylko druga potrzebuje nagłówków, które ludzie wklejają.
W witrynie, którą administrujesz, popraw adres zasobu, odpowiedź lub politykę u jej właściciela i zachowaj wymagania dotyczące autoryzacji i referrera. W witrynie, której nie kontrolujesz, wyślij stronę i dowody żądania do jej kanału wsparcia, zamiast publikować ponownie prywatne lub wygasające linki do zasobów.
Porównuj ścieżki bez zmieniania dowodów
Jeśli naprawdę chcesz przetestować ścieżkę dostępu, utrzymuj wszystko inne na stałym poziomie: ta sama strona, to samo konto, ten sam wybrany obraz, jedna dozwolona ścieżka zmieniona. Porównuj wpisy żądań obok siebie, a nie wyrenderowany wynik, bo wyrenderowany wynik mówi, czy obraz się pojawił, a nie dlaczego.
Obraz, który ładuje się na nowej trasie, nie dowodzi, że trasa jest autoryzowana, a obraz, który pozostaje złamany, nie dowodzi, że winny jest tunel. Jeśli obraz został usunięty lub dostęp jest celowo ograniczony, użyj wspieranego rozwiązania zastępczego, zamiast wyłączać sprawdzanie certyfikatów lub kopiować cudze chronione materiały.
Kolejność pracy: zidentyfikuj wybrany adres URL, odczytaj jego status i typ, sprawdź, czy istnieje zapisana przyczyna blokady, a następnie porównuj jedną zmianę ścieżki na raz.