Upgrading from Rails 6.0.3.6 to 6.1.3.1 causes PDF download trigger browser error: ERR_RESPONSE_HEADERS_TOO_BIG

[Arns]

Issue description

I used the render PDF option for my Rails app and all works well on version 6.0.3.6. I upgraded to Rails 6.1.3.1 and now all browsers throw the following error: ERR_RESPONSE_HEADERS_TOO_BIG. Note that I've done some investigating and it appears to be linked to my usages of <%= stylesheet_link_tag wicked_pdf_asset_base64("pdf") %>. I don't understand why that would suddenly be causing problems when upgrading to the new version of rails.

Expected or desired behavior

PDF should download as usual.

System specifications

wicked_pdf gem version (output of cat Gemfile.lock | grep wicked_pdf):
1.4.0
wkhtmltopdf version (output of wkhtmltopdf --version):
0.12.6
whtmltopdf provider gem and version if one is used:

platform/distribution and version (e.g. Windows 10 / Ubuntu 16.04 / Heroku cedar):
Doesn't apply.. error exists on Windows 10 edge/chrome, Ubuntu Chrome/Firefox

[mjtko]

Ok, I've bashed this about a bit, and it looks like it's a problem with behaviour introduced in rails/rails#39939 and then softened in rails/rails@c55e32e.

TL;DR: set this in application.rb:

config.action_view.preload_links_header = false

...Or do something else to prevent the massive data URLs being added to the Link header. Open to better ideas than entirely disabling application-wide for all URL types and will probably look into this more in due course. Feels like it's a Rails-side bug and it shouldn't include data URLs in Link?

[unixmonkey]

@mjtko Thank you for tracking this down! The latter commit you pointed to makes it look like you can call:

<%= javascript_include_tag('something', defer: false) %>

in at least the newest version of Rails.

[mjtko]

Yeah, unfortunately that doesn't seem like an option with stylesheet_link_tag (ref: L162 of asset_tag_helper.rb) I suppose as it doesn't make sense to "defer execution" of CSS (unlike JavaScript).

I still feel like the fix is probably not to add the preload link header for data URLs -- not really sure what the point of doing so would be as the asset is embedded in the page anyway, but I'm not entirely au fait with the mechanism. It strikes me that, at the very least, assets above a "max size" of some kind should not be added, so the maximum response header size can't be breached. In my case cURL suggests:

 * Rejected 147198 bytes header (max is 102400)!

But this is probably a discussion to have on a Rails issue somewhere. :-) I don't think this is something that wicked_pdf needs to worry about, other than possibly documenting somewhere.

[mjtko]

I had a quick glance at issues in the Rails repo and it looks like this PR might fix the problem (or at least hide it) in the next release of Rails. rails/rails#42056

It sounds like that fix still might cause a lot of data might be sent that doesn't need to be sent though.

[mjtko]

Just to update here, this issue now has a proposed fix in Rails: rails/rails#42197

I think this can be closed here, as it's not specific to wicked_pdf.

[byroot]

For anyone impacted by this, you can set config.action_view.preload_link_header = false as a workaround to disable this feature entirely.

[mjtko]

@byroot Thanks for your work on the fix (your multiple handles confused me!) and good thinking to make the last comment the workaround to save people having to read through the whole issue.

The workaround is as follows (from #971 (comment) above):

Set this in config/application.rb:

config.action_view.preload_links_header = false

(NB. preload_links_header (plural) not preload_link_header).