Closed GoogleCodeExporter closed 9 years ago
Screenshot.
Original comment by djben...@gmail.com
on 10 Jan 2012 at 2:09
Attachments:
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:
Zero byte download...
Original comment by djben...@gmail.com
on 10 Jan 2012 at 2:15
Attachments:
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
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
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
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
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:
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
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
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:
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
Removing the closing php tag makes no difference.
Original comment by djben...@gmail.com
on 10 Jan 2012 at 9:03
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
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
Just in case, here's my PHP.ini.
Original comment by samuli.j...@gmail.com
on 11 Jan 2012 at 6:19
Attachments:
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:
Any progress on this?
Original comment by samuli.j...@gmail.com
on 10 Apr 2012 at 6:45
Original comment by samuli.j...@gmail.com
on 26 Aug 2012 at 12:17
Original issue reported on code.google.com by
djben...@gmail.com
on 10 Jan 2012 at 2:07Attachments: