Грешки при прокси удостоверяване при HTML към PDF от отдалечени ресурси

HTML пристига като низ. Генерирането на PDF започва, после мрежово изключение споменава прокси удостоверяване. Погледнете в документа, преди да обвинявате PDF файла.

Рендерърът може да разрешава ресурси, посочени от входа му. Отдалечено изображение, стилова таблица, шрифт или поддържан импорт въвежда още една заявка. Кои типове ресурси се поддържат зависи от рендеръра; предоставянето на основната разметка не гарантира напълно офлайн преобразуване.

Намерете втория URL

Запишете ресурса, който рендерърът е изтеглял при неуспеха. Разрешавайте относителните препратки спрямо действителния базов URL. Безобиден на вид път до лого може да сочи извън приложението, когато тази база се различава от използваната в браузърния преглед.

След това идентифицирайте изтеглящия. Успешната заявка от вашия собствен HTTP клиент не конфигурира вътрешното извличане на ресурси на рендеръра. Използвайте документирания интерфейс за ресурси на рендеръра или одобрена схема за предварително извличане, ако има такава.

Идентификационните данни за приложението източник също не са автоматично прокси идентификационни данни. Рендерърът може да работи под идентичност на услуга с друга среда и друг мрежов път.

Направете зависимостта явна

За отчети, предназначени да работят офлайн, предоставяйте одобрени локални или вградени ресурси чрез поддържания механизъм. Ако са необходими отдалечени ресурси, направете разрешените им дестинации, удостоверяването и поведението при грешка част от дизайна на рендирането.

Липсващото лого и неуспешното преобразуване са различни възможни резултати. Проверете как библиотеката обработва грешки при извличане, вместо да обявявате отчета за завършен само защото е създаден PDF файл. Запазете неуспешния ресурс и етапа на заявката в диагностиката; многократната промяна на URL на оригиналния документ може да остави действителното изтегляне незасегнато.