500 Internal Server Error on linking to Files

Here's a bunch of random questions.

1) Are clean URLs working correctly otherwise?
2) Is your file system set for public download?
3) Can you access a file from /sites/default/files?
4) Does /drupal/sites/default/files/private/filename.pdf correctly redirect to /drupal/system/files/private/filename.pdf (before the error)?
5) With Private Download disabled is /drupal/sites/default/files/private/filename.pdf correctly inaccessible (protected by the .htaccess)?
6) What's your server setup?

Bottom line, we need to determine if the error is Private Download related or if it's something lower level and more fundamentally wrong with your web server configuration. I suspect it's the latter, but I (or perhaps another user) will attempt to at least point you in the right direction.

John

BTW, thanks for creating a separate issue. :-)

Hmm, all your responses are as expected. Your web server configuration is also pretty standard although you left out the OS (assumption is some flavor of Linux). I see you're using the default .htaccess content so there's no information to glean there either.

Since you're on a shared server you probably don't have access to the error logs. However even if you did they might not reveal anything because 500 Internal Server errors happen at a lower level before the web server has a chance to write to the log.

Switching from public to private and then back to public can be problematic, but mostly because it messes with pre-existing file entry paths in the database. It shouldn't matter with new files.

I suppose you could try creating a separate clean install and only enabled Private Download. This will either succeed (and therefore suggest there's a problem with your primary application configuration) or fail (and perhaps help to isolate the problem.)

Other than that I'm honestly stumped. The module should work as described without any fuss (especially when judging it by the limited number of bug reports and support issues.) Perhaps someone else can jump in with a comment or suggestion. Anyone?

That's actually very helpful, but unfortunately still not conclusive.

The error message suggests there's a problem with the "file headers" attributes. This could be due to case-sensitivity or possibly the incorrect number of line breaks after each entry.

Sometimes the only way to resolve this kind of problem is to get some sort of sniffer utility application that examines the page header data contents and formatting. This can be tedious and time-consuming. I'm admittedly not an expert on this sort of thing and I try to avoid it like the plague (for obvious reasons!)

Before going any further you might try opening a trouble ticket with your web host. Tell them you're getting an 500 Internal Server error and include the error message from the log. I still think it's a server configuration issue. They might not have an answer, but could provide a clue.

Another suggestion is to Google the name of your web host along with "malformed header from script" "Bad header". You might get some hits of people talking about the problem and possible resolutions.

There's gotta be a solution out there and you're likely not the first person to have encountered this problem. I have certainly dealt with my fair share of mysteries like this and persistence usually wins out. :-)

php-wrapper.fcgi sounds like it could be the culprit. Just for giggles why not try temporarily disabling it...?

See http://www.catskilltech.com/freeSW/SMF/faqs/index.html > "500 (Internal Server) Errors" and "Proper Permissions" to see if any of those things are getting you on your particular server.

(remove dupe). Stupid comment system.

You'll just have to slog through all your files and permissions. I'd concentrate on the "private directory" and its files, if your Drupal site works fine everywhere else. Are you sure there's nothing in the way of an error message specifying exactly what the server doesn't like? It might appear on screen (do a View > Page source) or be in a file such as error_log. Have you checked if your host bans "world writable" directories or files (and of course, do you have any)? Do you have any .htaccess entries restricting access to this directory? A badly formed .htaccess command could cause a 500 error, and if the .htaccess file is in the private directory, it would only be triggered when you actually go into that directory. If these are script files (e.g., PHP) you're linking to, are they valid (no blank lines at the beginning or end)?

Well, it looks like you have two problems. First, it's trying to send an HTTP header starting with, apparently, a "paragraph" tag. It should be something like "Content-type: text/html" (plus a blank line), I would think. This fcgi is "Fast CGI PHP"? Perhaps you need to explicitly send the header, as you would with a CGI Perl program? You might want to talk with your host about how to properly use this (is there a reason you can't use your server's ordinary PHP?).

Second, it appears that an "internal_error.html" file is supposed to be invoked, but isn't found. I can't tell you if Drupal is trying to call it, or if PHP or the server is doing it. A "500" error is also known as an "Internal Server" error, so I would guess that the server has tripped a 500/IS error, and is complaining that it can't find a custom error handler for that error. That's common to see Apache servers complain about not being able to find a custom error handler, even though a default one exists. Anyway, if that's all it is, you can probably ignore this second error, as it will go away once you fix the first error (the one actually triggering the 500 error). Think about providing some custom error handlers (error documents), per instructions from your host: 400, 401, 403, 404, and 500 errors at a minimum.

And I only get this problem when I have private_download enabled.

It's certainly possible the header structure sent by Private Download is incompatible with your web host and/or your particular server configuration.

Have you considered switching web hosts? One that allows you to adjust the memory and upload limits without all the workarounds and hoop-jumping.

pltmdude,

Funny, I didn't even think to ask if you had a WYSIWYG enabled. It was just too obvious, as you said. Sidebar rant: I seriously hate WYSIWYG editors and avoid them like the plague for this reason and more. Unfortunately many clients like them (ugh).

Anyway, that's good news.

John