Blank pages when returning buffer of generated PDF

[niamzor]

I'm trying to generate a PDF from an url and return this pdf without saving it to the server filesystem.

$puppeteer = new Puppeteer();
$browser = $puppeteer->launch([
    "ignoreHTTPSErrors"     => true,
    "args"                  => ['--no-sandbox', '--disable-setuid-sandbox']
]);
$page = $browser->newPage();
$page->goto($url, ["waitUntil" => "networkidle0"]);
$buffer = $page->pdf([
    "path"                  => $filepath,
    "format"                => "A4"
);
$browser->close();

return new Response(
    $buffer->toString(),
    201,
    [
        'Content-Type'          => 'application/pdf',
        'Content-Disposition'   => 'inline; filename="file.pdf"'
    ]
);

For testing purposes, I use the path option to actually generate a PDF on the filesystem. This generated PDF is absolutely fine whereas the one returned by Symfony in the client browser is blank, though the number of pages is alright.

I had tried to return a BinaryFileRespones or a StreamedResponse with no luck.

Any hints appreciated
puphpeteer.log

[jonnywilliamson]

I'm getting exactly the same thing. Thanks for letting me know that the data written to disk works!!

[nesk]

Related to #87

[spekulatius]

I've think I replicated this locally. I can confirm:

• The buffer is NULL after writing the file (for me).
• For my example page the PDF is rendered and around 10 MB in size after saving to the disk.

My best guess on the reason is:

• It exceeds the maximal length of CLI operations (xargs --show-limits) while passing through. On my system that is around 2 MB. Not entirely sure on this as I'm still working myself into the code.

My first thought on a work-around would be to drop back to the file-system in case of large operations such as generating PDFs or setting content (see #87). This would require to catch the calls/responses and write/load from the FS instead of relying on the passed information.

Does this match your impression @nesk ?

[nesk]

The communication between PHP and JS is done through sockets, not through CLI operations, I don't thing the limits shown by xargs apply here.

The real issue here is the poor implementation of the socket communication, the problem is described in rialto-php/rialto#12.

Rialto should be entirely agnostic, I don't think we should try to fall back to custom implementations (like the filesystem one) for some specific methods.

[spekulatius]

Ah okay. Good to know. Learned something more 👍