Apache and pdfs

[suityou01]

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

[DimPrawn]

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.

[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.

[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.

[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 ?

[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?

[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.

[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

[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.

[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.