O HTML chega como unha cadea. A xeración do PDF comeza, e entón unha excepción de rede menciona a autenticación do proxy. Mire dentro do documento antes de culpar o ficheiro PDF.

Un renderizador pode resolver recursos aos que fai referencia a súa entrada. Unha imaxe remota, unha folla de estilos, unha fonte ou unha importación admitida introduce outra solicitude. Que tipos de recursos se admiten depende do renderizador; fornecer a marcação principal non garante unha conversión totalmente sen conexión.

Localice a segunda URL

Rexistre o recurso que o renderizador estaba obtendo cando fallou. Resolva as referencias relativas contra a URL base real. Unha ruta de logotipo aparentemente inocente pode apuntar fóra da aplicación cando esa base difire da usada nunha vista previa do navegador.

Despois identifique o descargador. Unha solicitude correcta do seu propio cliente HTTP non configura a obtención interna de recursos do renderizador. Utilice a interface de recursos documentada do renderizador ou un mecanismo de captación previa aprobado se o ofrece.

As credenciais da aplicación de orixe tampouco son automaticamente credenciais do proxy. O renderizador pode executarse baixo unha identidade de servizo con outro ambiente e outra ruta de rede.

Faga explícita a dependencia

Para os informes destinados a funcionar sen conexión, forneza recursos locais ou incorporados aprobados mediante o mecanismo admitido. Se se requiren recursos remotos, faga que os seus destinos permitidos, a autenticación e o comportamento ante fallos formen parte do deseño da renderización.

Un logotipo ausente e unha conversión fallida son resultados posibles distintos. Comprobe como a biblioteca xestiona os erros de obtención en lugar de declarar o informe completo só porque se creou un ficheiro PDF. Mantena o recurso fallido e a etapa de solicitude no diagnóstico; cambiar repetidamente a URL do documento orixinal pode deixar a descarga real intacta.

Artigos relacionados