wifang / mollify

Automatically exported from code.google.com/p/mollify
0 stars 0 forks source link

All files show as JPEG MIME type when downloading and zero bytes when saved #348

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Install Mollify
2. Create configuration file
3. Attempt to download file

What is the expected output? What do you see instead?
When trying to download a file, everything is being output with a MIME type of 
"JPEG Image" - so PDF's, text files, everything. The browser shows the "Save 
as..." dialog showing file type (JPEG) and size, but when saved to the desktop 
the files are empty.

What version of the product are you using? On what operating system?
1.6.0.1 on Ubuntu 11.10 x64

Please provide any additional information below.
Output from the debug service;

Sending conlist.sh (2424), 16:Sent 3 chunks, 17:PHP error #2, Cannot modify 
header information - headers already sent (Unknown:0), 18:RESPONSE error 
{0:999, 1:Unexpected server error, 2:500} PHP error #2, Cannot modify header 
information - headers already sent (Unknown:0)}

I have deleted my full install, downloaded the zip, created a new 
configuration.php (using both vi and nano) so I don't know what else I can do.

Original issue reported on code.google.com by djben...@gmail.com on 10 Jan 2012 at 2:07

Attachments:

GoogleCodeExporter commented 9 years ago
Screenshot.

Original comment by djben...@gmail.com on 10 Jan 2012 at 2:09

Attachments:

GoogleCodeExporter commented 9 years ago
Same error from IE8 (although this shows the MIME type as "unknown")

Original comment by djben...@gmail.com on 10 Jan 2012 at 2:14

Attachments:

GoogleCodeExporter commented 9 years ago
Zero byte download...

Original comment by djben...@gmail.com on 10 Jan 2012 at 2:15

Attachments:

GoogleCodeExporter commented 9 years ago
You should enable debugging and get the error log after download, see 
troubleshooting wiki

Original comment by samuli.j...@gmail.com on 10 Jan 2012 at 3:56

GoogleCodeExporter commented 9 years ago
Sorry, there was debug info already. Sounds like this: 
http://code.google.com/p/mollify/wiki/Troubleshooting#Error_"Cannot_modify_heade
r_information"_or_"Got

So make sure there is NOTHING outside <?php ... ?> (and I mean nothing, no 
spaces or line feeds etc)

Original comment by samuli.j...@gmail.com on 10 Jan 2012 at 3:59

GoogleCodeExporter commented 9 years ago
Hi

I was very sure to check the WIKI for answers before posting this, and tried 
anything that seemed relevant but I still have this issue.

I also went to great lengths to ensure the configuration file was free of any 
erroneous characters (anybody using vi under linux is only doing so because 
absolutely necessary!)

A couple of points to note;

When viewing an image file, the thumbnail preview in the popup box works, but 
if I try and view the image in the larger popup box, the image never loads.

Text files can be loaded into the text editor but when trying to download they 
fail as per my original post.

Original comment by djben...@gmail.com on 10 Jan 2012 at 6:46

GoogleCodeExporter commented 9 years ago
Well, the error is quite clear, something starts the PHP output before it 
should, which prevents modifying the headers. Usually this is the 
configuration.php, because it's the only file users (usually) modify 
themselves, but of course it can be somewhere else as well. But if it was in 
one of the mollify files, I think this would occur in every installation.

Could you

a) post me your copy of configuration.php, just in case

b) get the full debug log from PHP error log after the download, it might give 
more info, like the row where the headers are sent

Original comment by samuli.j...@gmail.com on 10 Jan 2012 at 6:59

GoogleCodeExporter commented 9 years ago
configuration.php and php.log attached (hopefully with all personal info 
removed)

Original comment by djben...@gmail.com on 10 Jan 2012 at 7:25

Attachments:

GoogleCodeExporter commented 9 years ago
You are right about the configuration.php, it really does not have anything 
extra there.

So this is a bit mystery, but somewhere there is something that shouldn't be. 
You could try removing entirely the closing "?>" from the configuration.php, 
but I doubt it's this file at all. Have you modified other files?

However, the error message in your log is quite odd. It says the headers are 
sent at "Unknown:0", like it couldn't identify the place. Usually here is the 
exact file where the output is started.

This PHP bug report shows the same exact same error, and claims it to be due to 
output buffering issue: https://bugs.php.net/bug.php?id=9031

So if you have output buffering enabled, try disabling it.

Original comment by samuli.j...@gmail.com on 10 Jan 2012 at 7:36

GoogleCodeExporter commented 9 years ago
Nothing modified at all, this was a vanilla install. I'll check my PHP config 
when I get home but again it should be untouched as installed with Ubuntu. 

I did see the error log and noticed it couldn't identify the source of the 
error. 

I seem to recall it is possible to set a buffer length within PHP which can 
resolve the header issue but I guess with me hosting my own install with no 
bandwidth issues I could just disable it.

Will post back shortly.

Original comment by djben...@gmail.com on 10 Jan 2012 at 7:44

GoogleCodeExporter commented 9 years ago
So output_buffering was turned on in php.ini - I've turned it off, restarted 
the apache2 service but the problem is still happening. This time, the MIME is 
presenting itself as "Text Document" in Firefox 9.

Original comment by djben...@gmail.com on 10 Jan 2012 at 8:54

Attachments:

GoogleCodeExporter commented 9 years ago
My version of PHP is 5.3.6-13 - if yours is the same can you post your php.ini 
and I'll try that on my box?

Original comment by djben...@gmail.com on 10 Jan 2012 at 8:56

GoogleCodeExporter commented 9 years ago
Removing the closing php tag makes no difference.

Original comment by djben...@gmail.com on 10 Jan 2012 at 9:03

GoogleCodeExporter commented 9 years ago
I'm just looking at the code for OutputHandler.class.php and the lines around 
the failure (82, 83 and 89) make reference to supportOutputBuffer - is this in 
relation to PHP's output buffer functionality? If so I'm confused as to why 
that function is still failing now I've turned off the output buffer.

Original comment by djben...@gmail.com on 10 Jan 2012 at 9:11

GoogleCodeExporter commented 9 years ago
Could you send me your copy of OutputHandler, because my copy has lines 82, 83 
and 89 totally unrelated to downloading?

To be exact, version 1.8.6.1 file OutputHandler has following function (line 
number in left):

        public function sendResponse($response) {
82          header($this->getStatus($response));
83          header("Cache-Control: no-store, no-cache, must-revalidate");

            $data = $response->data();
            if (!$data) return;

            if ($response->type() === 'json') {
89              header('Content-type: application/json');
                echo json_encode($data);
            } else {
                header('Content-type: text/html');
                echo $data;
            }
        }

But this function is for responding to regular requests using JSON format, not 
downloading. So if your copy has something different, then you have some 
version mismatch or corrupt file etc.

The variable "supportOutputBuffer" is meant to support systems that do have PHP 
output buffering on, but this is something you have to enable explicitly, see 
http://code.google.com/p/mollify/wiki/BackendSettings#Support_for_output_buffer_
(_support_output_buffer_)

Original comment by samuli.j...@gmail.com on 11 Jan 2012 at 6:11

GoogleCodeExporter commented 9 years ago
Just in case, here's my PHP.ini.

Original comment by samuli.j...@gmail.com on 11 Jan 2012 at 6:19

Attachments:

GoogleCodeExporter commented 9 years ago
I just took the latest OutputHandler.class.php from SVN and it made no 
difference although to my untrained eye, the two copies are slightly different.

Original comment by djben...@gmail.com on 11 Jan 2012 at 7:08

Attachments:

GoogleCodeExporter commented 9 years ago
Any progress on this?

Original comment by samuli.j...@gmail.com on 10 Apr 2012 at 6:45

GoogleCodeExporter commented 9 years ago

Original comment by samuli.j...@gmail.com on 26 Aug 2012 at 12:17