Hi!
Thanks for using our plugin.
Sounds like there’s an issue with the HTTP headers that the plugin is trying to send. Probably something wrong with the Cookie header. Could you capture the actual HTTP request that the code generates when a 400 error occurs?
1. You should define the FETCH_COOKIES_ENABLED and other plugin related constants in your wp-config.php so it’s retained during plugin updates.
2. You could directly filter out the $_COOKIE array at an earlier point of wordpress code execution as a hack to this problem. Any action hook before template_redirect will work fine for our purposes.
Let me know if any of this helps. Please let me know if you find the problem causing a 400 error in the plugin. It sounds like something that needs a patch within the plugin code itself.
Cheers!
Antti
That turned the trick. I added an action to the “wp” action hook that tested for “/pdf/” or “/pdf-preview/” on the URL and then destroyed all the cookies that I didn’t want.
I logged out the cookies that were destroyed, and I suspect that the culprit was the one named:
function_(v)_{
____return_$_grep(this,_function(e)_{
________return_e_!==_v;
____});
}
That was an empty cookie, but I have no idea what it’s from or what it’s for.
The header when the 400 was thrown:
Accept:text/html
Cookie: pll_language=en; wp-settings-1=libraryContent=browse&editor=html&mfold=o&hidetb=1&posts_list_mode=list; wp-settings-time-1=1413321562; PHPSESSID=<deletedhash>; lat=<deletedlat>; lng=<deletedlng>; wordpress_test_cookie=WP Cookie check; wordpress_logged_in_<deletedhex>=squires|<deleteddigits>|<deletedhash>|<deletedhash>; product=40; basisWeight=80; size=255; unit=988; quantity=50; function_(v)_{
____return_$_grep(this,_function(e)_{
________return_e_!==_v;
____});
}=undefined; __unam=<deletedhash>
Perhaps the semi-colons or equals signs in the cookie name need to be escaped?
What gets me is just the sheer oinkheadedness of this cookie. I’m uncertain why anyone would want to pass a JavaScript function into a cookie, and why as the name instead of the value (like that makes any difference).
This really is quite odd. Did you ever find the source of that cookie?
Anyways, I’m Glad you found the issue. Marking this thread as resolved now!
Cheers!
Never did.
I posted the header as requested against the possibility that you might want to recreate the problem and smart up the plugin to work around foolishly ridiculous cookies. I read up enough on cookies to make me think that the semicolons and equals signs probably need to be escaped for proper cookie construction.
Regardless, the workaround is functional, and resolves the issue.
Thanks, Antti!
After reading up a bit on cookie encoding it looks like the cookie values should always be URL encoded, but not the keys. This alone wouldn’t solve your problem as the function was in the key, not the value.
To fix this I made it so that any cookies that contain non-ascii characters in their key portion, are simply not passed on at all, which should help avoid these situations.
Here’s the patch https://github.com/Seravo/wp-pdf-templates/commit/e11da5cc3ddb8781bf648fc75061a76d78de8c14
Updating the plugin on wordpress.org now…
Thanks for your help finding this!
I’m having an issue after upgrading from 1.3.5 from 1.3.6 and I think it’s related to the issue above.
Getting the following error when using /pdf
Warning: rawurlencode() expects parameter 1 to be string, array given in /wp-content/plugins/wp-pdf-templates/wp-pdf-templates.php on line 209
Unable to stream pdf: headers already sent
I really appreciate some help on this.
Thank you
Hi, blueocean!
My bad. I didn’t take into account the $_COOKIE array can apparently contain arrays as values, not just strings. This caused a PHP warning to be triggered, and with display_errors set to 1 in your php.ini, the error was echoed right onto the PDF file output, corrupting it.
I released a patch for this in 1.3.7. Just update the plugin and this should be fine.
Sorry about the inconvenience.
Thanks for the quick fix Antti.
I just did the update and it’s working perfect again.
Antti,
I updated to 1.3.7 and things didn’t go well. My cookie filter is still running, but the cookie construction on line 214 $header .= 'Cookie: ' . $_SERVER['HTTP_COOKIE'] . "\n"; completely goes around the filter, resulting in DOMPDF either giving up, or taking an unusually long time.
PHP Warning: file_get_contents(http://project.local/environmental-impact/?pdf-template): failed to open stream: HTTP request failed! in /wp-content/plugins/wp-pdf-templates/wp-pdf-templates.php on line 226
As you can see, the header once again has the problem cookie in it:
Accept:text/html
Cookie: pll_language=en; wp-settings-1=libraryContent%3Dbrowse%26editor%3Dhtml%26mfold%3Do%26hidetb%3D1%26posts_list_mode%3Dlist%26wplink%3D1; wp-settings-time-1=1413830985; PHPSESSID=222e0a42f8d0679517c2f04a43a32767; lat=32.8122051; lng=-96.81098519999999; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_32e602ee83bafa62a782a1a3d3a0ce85=squires%7C1414766042%7CgSLarpmuAieRtuIFmF6qHHUjmcFdk1rxkzMWsNUIUxe%7Cbd4454a8bc88d690e10931c1dcb1b03a83d61295b708621d0676a12bedc726c8; product=40; basisWeight=80; size=255; unit=988; quantity=50; function%20(v)%20%7B%0A%20%20%20%20return%20%24.grep(this%2C%20function(e)%20%7B%0A%20%20%20%20%20%20%20%20return%20e%20!%3D%3D%20v%3B%0A%20%20%20%20%7D)%3B%0A%7D=undefined; __unam=62276c-1490aff8e15-2735d8df-1195
Currently, I guess I would have to construct my own $_SERVER[‘HTTP_COOKIE’] value in my filter function?
That’s what I’ve done: used the filter that modifies the $_COOKIE array to also reconstruct $_SERVER[‘HTTP_COOKIE’]
Right now, this seems kind of brittle to me, but I figure that’s mostly because of the changes you’re making to accommodate my original request.
Thank you so much for your continued attention!
