O HTML chega como uma string. A geração do PDF começa, então uma exceção de rede menciona autenticação de proxy. Olhe dentro do documento antes de culpar o arquivo PDF.

Um renderizador pode resolver recursos referenciados pela sua entrada. Uma imagem remota, folha de estilo, fonte ou importação suportada introduz outra solicitação. Quais tipos de recurso são suportados depende do renderizador; fornecer a marcação principal não garante uma conversão totalmente offline.

Localize a segunda URL

Registre o recurso que o renderizador estava obtendo quando falhou. Resolva referências relativas contra a URL base real. Um caminho de logotipo aparentemente inocente pode apontar para fora da aplicação quando essa base difere da usada numa pré-visualização do navegador.

Depois identifique o downloader. Uma solicitação bem-sucedida do seu próprio cliente HTTP não configura a obtenção interna de recursos do renderizador. Use a interface de recursos documentada do renderizador ou um esquema aprovado de pré-busca, se houver.

As credenciais da aplicação de origem também não são automaticamente credenciais de proxy. O renderizador pode ser executado sob uma identidade de serviço com outro ambiente e outro caminho de rede.

Torne a dependência explícita

Para relatórios destinados a funcionar offline, forneça recursos locais ou incorporados aprovados através do mecanismo suportado. Se recursos remotos forem necessários, torne os destinos permitidos, a autenticação e o comportamento em caso de falha parte do design de renderização.

Um logotipo ausente e uma conversão falhada são resultados possíveis diferentes. Verifique como a biblioteca trata erros de obtenção em vez de declarar o relatório concluído apenas porque um arquivo PDF foi criado. Mantenha o recurso falhado e a etapa da solicitação no diagnóstico; alterar repetidamente a URL do documento original pode deixar o download real intacto.

Artigos relacionados