HTMLは文字列として届きます。PDF生成が始まり、その後ネットワーク例外がプロキシ認証に言及します。PDFファイルを責める前に、ドキュメントの中身を確認してください。

レンダラーは入力が参照するリソースを解決することがあります。リモートの画像、スタイルシート、フォント、対応するインポートは、さらに別のリクエストを発生させます。どのリソース種別に対応するかはレンダラー次第であり、メインのマークアップを渡しても完全なオフライン変換は保証されません。

2つ目のURLを特定する

失敗時にレンダラーが取得していたリソースを記録します。相対参照は実際のベースURLに対して解決してください。無害に見えるロゴのパスも、そのベースがブラウザのプレビューで使ったものと異なれば、アプリケーションの外を指すことがあります。

次にダウンローダーを特定します。自分のHTTPクライアントでの成功したリクエストは、レンダラー内部のリソース取得を構成するものではありません。レンダラーが文書化したリソースインターフェース、または承認された先読みの仕組みがあればそれを使ってください。

ソースアプリケーションの資格情報も自動的にプロキシの資格情報になるわけではありません。レンダラーは別の環境と別のネットワーク経路を持つサービスIDで動作することがあります。

依存関係を明示する

オフラインで動作させるレポートには、対応する仕組みを通じて承認済みのローカルまたは埋め込みリソースを提供してください。リモートリソースが必要な場合は、許可された宛先、認証、失敗時の挙動をレンダリング設計の一部にします。

ロゴの欠落と変換の失敗は異なる結果です。PDFファイルができただけでレポートを完成と宣言するのではなく、ライブラリが取得エラーをどう扱うかを確認してください。失敗したリソースとリクエスト段階を診断情報に残してください。元のドキュメントのURLを何度も変えても、実際のダウンロードには手が付かないことがあります。

関連記事