PDF Static Resource

A while back I posted about the correct configuration for a PDF static resource, which I understood to be "application/pdf". I set it up but couldn’t get it to work.

@opengeek responded that I should also be sure to make sure that the binary option was checked as well.

Without binary checked, I can download the PDF, but it downloads as an "application" in that my OS (OS X) prompts me that this is an application downloaded from the internet, do I want to open it. This doesn’t happen with PDFs from other sites, nor does it happen when I link directly to a PDF on this site. (i.e. a href="filename.pdf"). It opens, but there are obvious structural differences, objects moved around, large areas of no content where there should be, etc.

When I check binary, the server generates a 500 Misconfiguration Error (PHP 5.2.14, mysql 5, apache 1.3.33, MODX 2.0.2, online shared hosting situation).

As I’ve read more into this I’ve been wondering what modx is doing, if anything, to set MIME types, etc. If it’s relying on PECL which I understand to be standard in PHP 5.3+, could that be the problem?

Any other thoughts would be helpful as I can’t seem to think of anywhere else to go with this.

UPDATE:

I’ve been able to make this work seamlessly on a Windows server running php 5.2.14 that I control. It downloads the PDF just as expected. Evidently, there’s something that the hosting provider is doing that’s making it go screwy on my client project....

I’m probably going to start scouring through the modx code to try to figure out what MODx is TRYING to do, and what the HOST isn’t letting it do.... any ideas where I should start looking?

Get a tool that allows you to see the full response headers on the problem server and compare it to the good one.

OK... I’ve got the header for the good configuration, but I can’t get the header for the bad config since it generates a 500 error (unless I set binary to "no")

GOOD CONFIG
Status: HTTP/1.1 200 OK
Date: Mon, 27 Sep 2010 02:23:36 GMT
Server: Apache/2.2.11 (Win32) PHP/5.2.14
X-Powered-By: PHP/5.2.14
Set-Cookie: SALARMYSESS=9ohia2829mnttc1244hvls4ck1; expires=Mon, 04-Oct-2010 02:23:37 GMT; path=/onlinechurch/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: public
Pragma: no-cache
Content-Disposition: attachment; filename=2
Vary: User-Agent
Content-Transfer-Encoding: binary
Content-Length: 176837
Connection: close
Content-Type: application/pdf

BAD CONFIG (with binary set to no):
Status: HTTP/1.1 200 OK
Date: Mon, 27 Sep 2010 02:26:40 GMT
Server: Apache
Cache-Control: public
Content-Disposition: attachment; filename=current-calendar.pdf
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Vary: User-Agent
Set-Cookie: PHPSESSID=tf5l8qer5kg1rkfvmbhnots3n5; expires=Mon, 04-Oct-2010 02:26:40 GMT; path=/
Connection: close
Transfer-Encoding: chunked
Content-Type: application/pdf; charset=UTF-8

I know know enough about apache to know why it would be generating a 500 error, or how to change it. Any suggestions, anyone?

We need to know why it is generating the 500 error. Is there not anything in the Apache error_log (or wherever your Apache/PHP configuration is set to log PHP errors) generated when you have it set to binary and get the 500? Or the MODx error.log file in core/cache/logs/?

@opengeek.... I knew you were going to say that

I looked through the modx error log and didn’t see anything at all in there other than a few notices a previous install. It’s a crappy GoDaddy economy hosting plan that my client has and GoDaddy doesn’t give "Economy" people the privilege of accessing their apache error logs. I have another client who has a stepped up plan that will let me, so I’m going to try it there and post back with the results.

thanks for the help so far.

I’ll be back soon.

OK.....

Here’s where I am.

First, I switched to another hosting account account (this time with logging privileges). The error logged on the 500 error was this:

[Tue Sep 28 08:58:40 2010] [error] [client 66.195.203.33] malformed header from script. Bad header=inline: /var/chroot/home/content/w/h/y/whynot1970/html/colsenkeane/index.php

Now, I knew I had set the disposition to "attachment" - so I went back.... saved the resource as inline, then saved it again as attachment, cleared the cache and now.... no 500 error.

But still no luck.

It does generate a PDF but not my OS says, "Can’t open this PDF because it’s empty." Sure enough, 0kb.

But now, MODx is generating an error, whereas it wasn’t before.

The MODx error now is this:

[2010-09-28 09:08:25] (ERROR @ /colsenkeane/index.php) Error caching resource 22

Maybe not very helpful, but at least I’m past the Apache 500 error stage.

Any thoughts?

A bit perplexed here; I can’t get it to fail for me so far with anything resembling those issues. It works fine as inline or attachment for me with the 1.5Mb PDF I am testing with. I’ll try to find another environment to reproduce the issue, but I am at a loss at the moment.

Hi all, this gives me the creeps too..

On my local Windows WampServer running PHP Version 5.3.0, I manage to get this done, running smooth for inline and attachment.
On my shared hosting server running PHP Version 5.2.13 i’m getting Error 404. I don’t know about configuration or any differences but i manage to do a workaround.

1)Open the file /core/model/modx/modstaticresource.class.php
2)Comment the line 150 and add the following codes below :

//LINE 150//$header= ’Content-Disposition: ’ . $this->get(’content_dispo’) ? ’inline’ : ’attachment’ . ’; filename=’ . $name;
$header = ’Content-Disposition: ’;
$header .= $this->get(’content_dispo’) ? ’attachment’ . ’;filename=’ . $name : ’inline’;

It worked for me for inline and attachment.

Hope this helps, cheers!

@star_faeiz: Thanks!! OK, making some progress here.

I’ve implemented the work around on at least one of the shared host sites that I’m operating and we’re 95% there. The PDF downloads, and opens in my default PDF reader.

The only remaining issue is that doesn’t append any file extenstion to PDFs or any of the content types (do I need to have friendly URLs enabled for this? At this phase in development, I do not).

UPDATE: This behavior (not appending file extension) seems to be browser specific now.... Chrome/Safari append the .pdf, Firefox does not (cleared cache, etc). Haven’t tried in IE yet.. IE does not append the extension either.

@opengeek: does this make sense? I don’t understand why this would work on some configs and not others.