I am doing below code in Laravel 5.5 with mpdf 8.0
$mpdf = new \Mpdf\Mpdf();
$mpdf->WriteHTML('Hello World');
$mpdf->Output("test","I");
It outputs gibberish/garbage values, seemingly showing pdf file in raw form.
Some findings
If I use $mpdf->Output($reportPath, 'F'); (saving it to file) and the opening that. It opens the file as expected.
If I place die(); after $mpdf->Output("test","I"); it shows the document.
My suspicion is, it has something something to do with Content-type:application/pdf not being set by default but I have also tried using header("Content-type:application/pdf"); before Output but of no use. it is still showing Content-Type: text/html; charset=UTF-8 in response header in Network tab of chrome (also tried Firefox).
Some back-story
It used to work on php7.3 just fine, but I have to update it to php7.4 due to some library and multiple application on a single server scenario.
Also start using a sub-domain for my application instead of placing the directories after the domain.
I'm looking for
A solution that doesn't require me to place die; at the end of output.
Or some clue in on why this has started happening or/and perhaps why I need to place die; after Output.
Any other solution.
The goal is to provide some ref. for people encountering same issues in future, since I have spent hours and haven't anything that specifically address such issue.
Ok, so I found out that I can't just rely on $this->mpdf->Output('test.pdf',"I") to output my result (though it was working previously with the same line) to the browser.
Because for some reason it has started to send Content-Type:text/html value in Content-Type header so I had to change that.
Solution
I did it as below:
return response($this->mpdf->Output('test.pdf',"I"),200)->header('Content-Type','application/pdf');
Related
This is an example for an image that I add to the image_urls field.
http://static.zara.net/photos//2014/I/0/2/p/5875/309/800/2/w/1920/5875309800_1_1_1.jpg
Yet I get this warning and the image is not uploaded.
[zara_com] WARNING: File (code: 404): Error downloading image from http://static.zara.net/photos//2014/I/0/2/p/5875/309/800/2/w/1920/5875309800_1_1_1.jpg> referred in
Though an image like this one:
http://static.zara.net/photos//2014/V/1/3/p/1280/303/105/2/w/1920/1280303105_2_1_1.jpg
is uploaded normally.
What might be the problem? what should I check?
As far as I can see, they seem to be filtering requests made with the default scrapy user agent:
'User-Agent': 'Scrapy/0.24.2 (+http://scrapy.org)'
When I changed the USER_AGENT setting in settings.py of my project, it started returning 200 on all requests. The strange thing is that before that it returned 404 even on the image, which you said is returned normally.
P.S. It's not very good to scrape content from a site, if they are not allowing it, but well it's not like they are disallowing it in their robots.txt. Still you should probably enable the RobotsTxtMiddleware and the AutoThrottle extension to ensure you are playing fairly.
I have a newsletter system that keeps track of the people who read it. Although this function works only if permission is given to download the images. But this is not my problem at this time.
My problem is that when I open an newsletter in Outlook (2010) and I give permission to download the images, my system doesn't register this view. But when I open the same newsletter in gMail, it works without any problem. Even when I use Outlook to save the e-mail to a HTML file and I open this file, a new view is registered. The page that save's the view and renders an 1x1 image, doesn't return any errors and no errors can be found in the Apache logs.
The strange thing is that it still worked until a week ago. But even if I put backups of the code, it still doesn't work....
The image url is build up with an base64 encodes string, for example:
http://domain.com/tracker/eyJtYWlsaW5nSWQiOiI4MjQiLCJjb250YWN0SWQiOjM3MzA5LCJjaHVuayI6ImIyYmNiNzhkNjAyMmVmNzQ0NmM4ZDA0YzU1ZGZhMTY0In0=/
In this encodes string, I have a JSON string that contains the newsletter id, a contact id and a MD5 string which I use to validate the data.
I run of ideas what to do to fix or debug this issue. Does anyone have a tip or even better, a solution? :) It it possible that Microsoft updated Outlook to prevent it from downloading this kind of images?
Check if you are sending correct MIME
I suggest using extensions in url example: .png .jpg
Try different domain.
This is the code for generating the image:
header('HTTP/1.0 200 Ok');
header("Content-type: image/png");
$trackerImage = imagecreate(1, 1);
$bgColor = imagecolorallocate($trackerImage, 255, 255, 255);
imagepng($trackerImage);
imagedestroy($trackerImage);
This always worked until a hardware crash of the server 2 weeks ago... The hosting company claimes nothing has been changed to the servers configuration.
I already tried adding an extions to the image path, but that didn't make a difference for Outlook.
Try to set the HTML code to display the image as if it's a larger image. Or even better, just display a normal image along.
I just happen to resolve this issue. The cause appeared to be fairly simple, but very difficult to detect.
When saving data about a user, I also requested the user-agent. In the database, I had a varchar (255) field in use for this information. However, the user-agent Outlook proved to be more than 255 characters. So this resulted in an error message from the database so that no image was generated.
It's the first time I am doing something with headers. I am mainly concerned with Cache-Control but there may be others I will need to check as well. For example, I try to send the following header to the browser (based on tutorials I just read):
Cache-Control:private, max-age=2011-12-30 11:40:56
Google Chrome displays it this way in Network -> Headers -> Response headers, but how do I know if it's correct, that there aren't any typos, syntax errors and such? Will it really work? Will the browser behave like I want it to, or will it treat it like a gibberish (something like "unknown header/value")? I've tried sending nonsensical headers on purpose but they got displayed with the rest. Is there any Chrome tool / addon for that, or any other way? Thank you in advance!
I'm afraid you won't be able to check if the resource has been cached by proxies en route, but you can check if your browser has cached it.
While in the Network panel of Chrome DevTools, hit F5 to reload your page. You should see something like "304 Not Modified" in the status field for the resource you are treating (which means the resource has not been modified and its contents were not received from the server but rather loaded from the browser's cache.)
I want to change the settings of firefox so as to allow it to make cross domain ajax calls. Since due to the security feature of the firefox it doen't allow ajax calls to be made. I know if it is in same domain it will allow. I have a code given bellow which in safari works fine but firefox doesn't display the results when it calls csce server then since the code is on local machine doesn't allow it and returns error. I know it will start working if I load my this code to csce server but I want to run the code from my machine. So can anyone help me in resolving this. I have spent past couple of days just searching for this solution.
Kindly suggest how to achieve this or should I go with some older version of firefox?
I googled and set the parameters of browser in config file as specified in this site but it still doesn't work.
http://code.google.com/p/httpfox/issues/detail?id=20
Maybe you could use privoxy and tell it to inject something like "Access-Control-Allow-Origin: *" in the server response.
To do this, you would have to go into the file user.filter (create it if it doesn't exist) in privoxys configuration directory and insert something like this:
SERVER-HEADER-FILTER: allow-crossdomain
s|Server: .*|Access-Control-Allow-Origin: *|
Instead of Server, you can also use any other header that's always present and you don't need.
And this into user.action:
{+server-header-filter{allow-crossdomain}}
csce.unl.edu
Note: I didn't test it.
https://developer.mozilla.org/En/HTTP_access_control
http://config.privoxy.org/user-manual/
This appears to enable XSS from file:// pages in Firefox 4, although it prompts you so might not be suitable for more than simple test pages:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
I'm using script which is uploading files to server via flash component. Sometimes, very rarely, when trying to upload images via Firefox I get following error: IO error #2038. Searching on the net I could find reason why is it really happening to me. But I found solution for my case:
I open IE6, do the same thing there (photos are always uploaded without problem) and the when I try again in Firefox problem disappears. If someone had similar problems maybe this could help or maybe this hint could help to someone discovering cause of the problem :)
I just had this error also using ASP.Net MVC and I discovered I just had my handler namespace wrong/missspellled in the web config section where the handlers go. HTH...
After far more time than I'd like to admit, here is the solution. Change the following variables in your php.ini to be large enough to handle your largest file:
; Maximum size of POST data that PHP will accept.
post_max_size = 32M
; Maximum allowed size for uploaded files.
upload_max_filesize = 32M
; Whether to allow HTTP file uploads. (this is on by default)
file_uploads = On
Since files are sent as POST data, both the first variables need to be set. Otherwise, there will be an error, but you won't see what the error is, except IO error #2038.
If you didn't add quote around the option names, try doing that. Sometimes in IE, quoting the option names fixes the issue. It would help if you posted some example code though.
Also make sure that the path to the server being used by the upload component is correct. If the path is a relative path, try to fully qualify it. IE can do some "magic" with relative paths that the other browsers cannot do, and sometimes trying the code from one browser to the other can tweak things.
Also, could be permissions...and having IE go there first could manipulate the permissions in a way that the other browser(s) then work "correctly".
I solved the problem.
In my office I use a proxy and I must change the settings to No Proxy.
Or if you do not use proxy, try to change in php.ini:
Hostname:Port localhost:0
to:
Hostname:Port localhost:80