Controlled Document PDF preview fails with embedded images using platform:// URLs
Summary
Printing a Controlled Document containing embedded images produces a PDF object, but Huly displays Failed to preview and the generated file cannot be downloaded.
Regular Huly Documents containing embedded images print correctly. The issue appears specific to documents:class:ControlledDocument.
Environment
- Deployment: Huly self-hosted
- Huly version:
v0.7.426 - Print image:
hardcoreeng/print:v0.7.426 - Browser: Chrome 151 on Windows
- Document class:
documents:class:ControlledDocument
The print service is configured with FRONT_URL, ACCOUNTS_URL, STORAGE_CONFIG, and PRINT_URL according to the self-hosting documentation.
Steps to reproduce
- Create or open a Controlled Document.
- Insert an image into its content.
- Select the PDF print/export action.
- Wait for PDF generation.
- Attempt to preview or download the generated PDF.
Expected behavior
The Controlled Document should be exported to a downloadable PDF containing its embedded images, as happens with regular Huly Documents.
Actual behavior
- The print endpoint returns HTTP 200.
- Huly displays
Failed to preview. - The generated PDF cannot be downloaded.
- The print service reports failed requests for embedded images.
Relevant log
requestfailed
errorText: net::ERR_UNKNOWN_URL_SCHEME
url: platform://platform/files/workspace/?file=<redacted-file-id>The same image is available during normal document viewing through the /files/... HTTP endpoint.
Additional observations
- Controlled Documents without embedded images can be printed.
- Regular Huly Documents with embedded images can be printed.
- The affected images were copied from another Huly document.
- The images exist in Huly storage and display normally in the Controlled Document.
- No guest tokens, authentication errors, storage errors, or HTTP 5xx responses were observed.
Suspected cause
The guest rendering path used to print a Controlled Document leaves embedded image sources in Huly's internal format:
platform://platform/files/workspace/?file=<file-id>Headless Chromium does not support the platform:// scheme.
The Controlled Document guest renderer may need to resolve these references to authenticated HTTP(S) /files/... URLs before Puppeteer calls page.pdf().
Possible fix
Resolve internal file references in the Controlled Document guest renderer, or replace platform://platform/files/... image sources with guest-accessible HTTP(S) URLs before PDF rendering.
Security note
All workspace IDs, file IDs, document content, domains, and guest tokens have been redacted.
Source: hcengineering/platform