Reply to: Apache and pdfs

[Sysman]

So it looks like as I built this machine from the latest bits the php version is too high and hence I have a build problem.

PHP can be a bit of a swine with the deprecated stuff. I had a fair old bit of digging and updating of code to do when I went to 5.3. I've still got some websites to switch over and check they don't barf.

I restarted apache out of desperation.

It works.

A luverly little pdf gets opened up.

Excellent news!

[fullyautomatix]

I restarted apache out of desperation.

It works.

A luverly little pdf gets opened up.

Off for a glass of vino, before coming back and pozzie repping everyone in this thread. Time for some suity loving, you better buckle up.

Well done on the debug. What a win-win, SuitYou sorted his problem and we all got his positive rep.

[NickFitz]

I restarted apache out of desperation.

It works.

A luverly little pdf gets opened up.

Off for a glass of vino, before coming back and pozzie repping everyone in this thread. Time for some suity loving, you better buckle up.

[suityou01]

I restarted apache out of desperation.

It works.

A luverly little pdf gets opened up.

Off for a glass of vino, before coming back and pozzie repping everyone in this thread. Time for some suity loving, you better buckle up.

[suityou01]

The correct (ie non deprecated code would be)

case 'I':

			//Send to standard output
			//if(isset($HTTP_SERVER_VARS['SERVER_NAME']))
			if(isset($_SERVER['SERVER_NAME']))
			//if (true)

			{

				//We send to a browser

				Header('Content-Type: application/pdf');

				if(headers_sent())

					$this->Error('Some data has already been output to browser, can\'t send PDF file');

				Header('Content-Length: '.strlen($this->buffer));

				Header('Content-disposition: inline; filename='.$name);

			}

			echo $this->buffer;

			break;

Which now steps into the branch but the moment the Content_Type is set I get a blank page

I added the line

error_reporting(E_ALL);

just before the output but again I still get a blank page.

So yes it is the content type not being set correctly, but when you set it then it loads nothing at all.

[suityou01]

Post the php here, I'm sure NF or similar here will spot the problem in no time.

Hokeydokes. I shan't post all the php code, only the relevant bit.

Our good friend pdf.php executes Print.php (I know follow how it all links together after some reading through the code)

Print.php renders the pdf like this

$pdf->Output("Invoice.pdf", "I");

Where $pdf is an instance of the Invoice class. The two arguments here are the name of the document to create, and the second argument is to do with the Content-Type.

The pertinent bit in the Output method of the invoice class looks like this

switch($dest)

	{

		case 'I':

			//Send to standard output
			if(isset($HTTP_SERVER_VARS['SERVER_NAME']))
			//if (true)

			{

				//We send to a browser

				Header('Content-Type: application/pdf');

				if(headers_sent())

					$this->Error('Some data has already been output to browser, can\'t send PDF file');

				Header('Content-Length: '.strlen($this->buffer));

				Header('Content-disposition: inline; filename='.$name);

			}

			echo $this->buffer;

			break;

So we know the flag is set to "I" so the only thing that can stop this branch from working is if

if(isset($HTTP_SERVER_VARS['SERVER_NAME']))

is returning false.

This document explaining what $HTTP_SERVER_VARS actually is makes me nervous

$HTTP_SERVER_VARS [deprecated]

$_SERVER -- $HTTP_SERVER_VARS [deprecated] — Server and execution environment information
Report a bug
Description

$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here. That said, a large number of these variables are accounted for in the » CGI/1.1 specification, so you should be able to expect those.

$HTTP_SERVER_VARS contains the same initial information, but is not a superglobal. (Note that $HTTP_SERVER_VARS and $_SERVER are different variables and that PHP handles them as such)

So it looks like as I built this machine from the latest bits the php version is too high and hence I have a build problem.

Now fecking idea where next. I tried removing the if case and just setting the Content_Type anyway, but I then get an empty page loading instead.

OK NF, over to you.

[DimPrawn]

Post the php here, I'm sure NF or similar here will spot the problem in no time.

[Sysman]

Yikes. Mod-Rewrite looks like a nightmare to get to grips with.

The trick is to look for examples.

What is frustrating was this was all working superbly on the server before it crashed to it can only be a configuration problem.

Are you sure some updates haven't slipped in somewhere? Either on the client or server side...

I know that Firefox messed up some stats downloads I used to do because a new version added .txt files to the MIME types.

[suityou01]

If there has been any output to the browser ( like a print statement etc) then you will see the raw output instead of a download.

can you show a screenshot ?

It is definately the raw content of the pdf. I have confirmed this now.

Bit of a long shot but the link that opens this corrupted view of the document, what if you use the old trick of right-click, save as...?

Also, have you tried in a couple of different browsers? For instance Chorme has PDF viewing built-in and another browser might not.

Neither is a fix but a slim chance it might work as a short-term measure?

If I do view page source, and then save this then I can open this as the pdf so at least I have a workaround, a lengthy one but a workaround at least.

Look at the properties, or page info of the page in the browser and check it's receiving the MIME type you've set.

It is text. I installed live headers in FF to check this.

To make certain the MIME type is being sent to the client correctly, install Fiddler (if you're on Windows) or Charles (if you're not) - N.B. I mean install on the client, not on the server. Either of them should automatically configure the browser to use it when launched, so fire it up and request an invoice, then look at the response properties to ensure that the Content-Type header is set to the value application/pdf.

As the PDFs are displaying their raw content you will presumably find that this is not the case, so you need to determine why not. The situation is complicated by the fact that you are creating the PDFs from a PHP script; a lot depends on how you actually get to the script.

Assuming you have something like http://myserver.local/invoice.php?id=42 then there is, by default, no way for the server to realise that the content has the MIME type application/pdf as a PHP script can produce content of any type, and the default MIME types mapping relies on file extensions.

This suggests three possible approaches: the first, assuming a URL like the above, is a mod-rewrite rule to tell the server that all content from invoice.php should be served as application/pdf, the second is to add a mod-rewrite rule to map invoice.pdf to be served from invoice.php and change the links thereto accordingly, and the third is to add a line to the PHP to set the Content-Type header directly; note that this must be placed before any other output, even of whitespace, has occurred:

header('Content-Type: application/pdf'); 

One of those ought to do the trick. If you know the PHP code the third is easiest, otherwise the first is probably the one to try. Give them a go and report back

Yikes. Mod-Rewrite looks like a nightmare to get to grips with. The php page in question has a URL like

php?print&docid=blah&module=jcrminvoice

So somehow the sugarcrm app locates the jcrminvoice module and it ultimately drills down to a page called html2pdf.pdf. My php is rusty so I'm leafing through all this code and getting a cloudy brain. I can see all the component parts just not how they fit together.

I thought I better check that mod-rewrite was installed and enabled just in case. It now is but it is no different. There is more chance of me completing the London to Brighton than me understanding mod-rewrite and actually doing something sensible with it.

What is frustrating was this was all working superbly on the server before it crashed to it can only be a configuration problem.

[NickFitz]

To make certain the MIME type is being sent to the client correctly, install Fiddler (if you're on Windows) or Charles (if you're not) - N.B. I mean install on the client, not on the server. Either of them should automatically configure the browser to use it when launched, so fire it up and request an invoice, then look at the response properties to ensure that the Content-Type header is set to the value application/pdf.

As the PDFs are displaying their raw content you will presumably find that this is not the case, so you need to determine why not. The situation is complicated by the fact that you are creating the PDFs from a PHP script; a lot depends on how you actually get to the script.

Assuming you have something like http://myserver.local/invoice.php?id=42 then there is, by default, no way for the server to realise that the content has the MIME type application/pdf as a PHP script can produce content of any type, and the default MIME types mapping relies on file extensions.

This suggests three possible approaches: the first, assuming a URL like the above, is a mod-rewrite rule to tell the server that all content from invoice.php should be served as application/pdf, the second is to add a mod-rewrite rule to map invoice.pdf to be served from invoice.php and change the links thereto accordingly, and the third is to add a line to the PHP to set the Content-Type header directly; note that this must be placed before any other output, even of whitespace, has occurred:

header('Content-Type: application/pdf'); 

One of those ought to do the trick. If you know the PHP code the third is easiest, otherwise the first is probably the one to try. Give them a go and report back

[VectraMan]

Look at the properties, or page info of the page in the browser and check it's receiving the MIME type you've set.

[d000hg]

Thanks for your response. I created a .htaccess file in the web directory in question and added the mime type. I restarted apache. No joy.
So I added the mime type to the apache config file. I restarted apache. No joy.

I am getting desperate as if I cannot get this working I cannot get my sales invoices out of SugarCRM and my accountant needs them urgently.

Sitting here on a Saturday night feeling very very depressed.

Bit of a long shot but the link that opens this corrupted view of the document, what if you use the old trick of right-click, save as...?

Also, have you tried in a couple of different browsers? For instance Chorme has PDF viewing built-in and another browser might not.

Neither is a fix but a slim chance it might work as a short-term measure?

[fullyautomatix]

If there has been any output to the browser ( like a print statement etc) then you will see the raw output instead of a download.

can you show a screenshot ?

[suityou01]

Don't know apache but it will be the MIME types no doubt.

Adding MIME types - Apache .htaccess Guide, Tutorials & Examples

So basically the web server needs to tell the browser the file contents are a PDF in the HTTP header.

Thanks for your response. I created a .htaccess file in the web directory in question and added the mime type. I restarted apache. No joy.
So I added the mime type to the apache config file. I restarted apache. No joy.

I am getting desperate as if I cannot get this working I cannot get my sales invoices out of SugarCRM and my accountant needs them urgently.

Sitting here on a Saturday night feeling very very depressed.

[yorkshireman]

I have just rebuilt my SugarCRM app from backups after a massive server crash. I used an ubuntu virtual machine to get me out of trouble as I just need to retrieve some sales invoices for my year end accounts.

It all works fine apart from when I try and open the invoices. It calls out to a php script that should render the pdf in the browser. Instead I get the contents of the pdf in the browser. By contents I mean raw contents.

Any ideas? Is there some apache setting I need to twiddle?

TIA

Suity

As the previous poster said. If the problem is that you have an existing pdf on the server and apache does not present it to the browser correctly then it is an Apache Mime types issue.

However if you have a PHP script that dynamically generates the Pdf on the fly from a database e.g. TCPDF then you need to find out which pdf script is missing. You should check the PHP logs on the server for errors where an include file is missing. Then Google for the file and install it.