wicked_pdf
wicked_pdf copied to clipboard
mileszs
PDF randomly generated without styles
Issue description
Some of the generated pdf files have no styling. This happens apparently randomly.
Expected or desired behavior
Files are consistently generated with the styles.
Analysis
The underlying issue is not caused by the gem directly.
What happens is that sometimes the wicked_pdf_stylesheet_link_tag (or any other helper inlining js or css assets) returns an empty style tag.
It can happen when the asset is fetched over the network (through a CDN for example) and the HTTP calls does not manage to get the asset properly (returning any non 2XX code - note that 3XX are also not followed).
In our case, the issue is that our CDN sometimes returns the asset properly, sometimes it returns a 301, apparently depending on the location of the caller. We don't know yet why this is happening.
As said above, this is not due to the gem. But this inconvenience made me wonder if we could fetch the assets from the filesystem instead of from the network (as in my case, the pre-compiled assets are still on the FS). So I created PR #1007 as an attempt to improve this.
System specifications
A priori not relevant here, see analysis section above.
I got answers regarding the CDN issue.
Our CDN doesn't use the protocol in the caching mechanism (which is apparently expected, I am not qualified enough to know why sorry!). So depending on the first request that is made to the assets, whether it is over HTTP or HTTPS either a 301 or a 200 is cached.
If by any chance it is the 301 redirect response, then we were screwed.
Now after changing the CDN configuration properly, to only retrieve assets over HTTPS, calls using HTTPS returns the assets consistently, and calls using HTTP returns a 301 redirect. I ran into another issue where pdf files were generated properly in a request/response cycle, but again without styles if generated into a background job.
That is because the gem uses the request protocol if there is one, otherwise it uses HTTP by default.
This was solved by adding default_protocol: 'https' to WickedPdf default configuration.
Apart from the performance consideration from above, I wonder if it wouldn't be good to raise an error in case the asset cannot be fetched instead of failing silently? Regarding 301 redirects, maybe following redirect is also an option?
if any of the style files uses custom font(needs to be imported from outside url or even within the project directories) try to comment it out and give it a shoot if the problem disappeared so it's a custom font issue
if any of the style files uses custom font(needs to be imported from outside url or even within the project directories) try to comment it out and give it a shoot if the problem disappeared so it's a custom font issue
Hey @mostafasobh thanks for your idea!
As I described above, it was not linked to custom font issue but directly to the stylesheet that was sometimes not retrieved due to the configuration of the CDN.
I was just hit by this issue after migrating from 1.2 (very old, I know).
Before 2.0.1 WickedPdf used open-uri to fetch the URLs of the assets which followed the redirects.
After 2.0.1 WickedPdf uses Net::HTTP.get which does a very nasty thing of returning empty string if the server responded with 301 Found.
In our case the problem was also with http vs https (CDN redirects from one to the other). It would be great if WickedPdf returned anything debuggable (error, warning, anything) when it happens.
