Błędy uwierzytelniania proxy przy konwersji HTML do PDF ze zdalnych zasobów
Znajdź żądania zasobów wtórnych, gdy generowanie PDF z HTML napotyka wyzwanie proxy, mimo że dokument główny został odebrany lokalnie.
HTML przychodzi jako ciąg znaków. Generowanie PDF zaczyna się, a następnie wyjątek sieciowy wspomina uwierzytelnianie proxy. Zajrzyj do dokumentu, zanim obwinisz plik PDF.
Renderer może rozwiązywać zasoby, do których odwołuje się jego dane wejściowe. Zdalny obraz, arkusz stylów, czcionka lub obsługiwany import dodaje kolejne żądanie. To, które typy zasobów są obsługiwane, zależy od renderera; dostarczenie głównego znacznika nie gwarantuje całkowicie offline'owej konwersji.
Znajdź drugi URL
Zapisz zasób, który renderer pobierał w chwili błędu. Rozwiązuj odwołania względne względem rzeczywistego bazowego URL. Niewinnie wyglądająca ścieżka logo może wskazywać poza aplikację, gdy ta baza różni się od używanej w podglądzie przeglądarki.
Następnie zidentyfikuj downloader. Udane żądanie własnego klienta HTTP nie konfiguruje wewnętrznego pobierania zasobów przez renderer. Użyj udokumentowanego interfejsu zasobów renderera lub zatwierdzonego mechanizmu wstępnego pobierania, jeśli jest dostępny.
Poświadczenia aplikacji źródłowej również nie są automatycznie poświadczeniami proxy. Renderer może działać pod tożsamością usługi z innym środowiskiem i inną ścieżką sieciową.
Uczyń zależność jawną
W przypadku raportów przeznaczonych do pracy offline dostarczaj zatwierdzone lokalne lub osadzone zasoby za pośrednictwem obsługiwanego mechanizmu. Jeśli wymagane są zasoby zdalne, uczyń ich dozwolone miejsca docelowe, uwierzytelnianie i zachowanie przy błędzie częścią projektu renderowania.
Brakujące logo i nieudana konwersja to różne możliwe wyniki. Sprawdź, jak biblioteka obsługuje błędy pobierania, zamiast ogłaszać raport ukończonym tylko dlatego, że utworzono plik PDF. Zachowaj nieudany zasób i etap żądania w diagnostyce; wielokrotna zmiana URL oryginalnego dokumentu może pozostawić rzeczywiste pobieranie nietkniętym.