Binary junk coming out of parsing index.php

[Tarique Sani]

1) (menalto) gallery 1.x is database driven afaik

You are wrong here   1.x uses flatfiles - 2.x which is in alpha since a year uses the db

[JMelhuish]

1) (menalto) gallery 1.x is database driven afaik

Actually it is flatfile, not DB

2) Coppermine does work on apache 2 webservers when the webserver is properly configured

I honestly don't know if this apache 2 webserver is configured properly, or not.  It is a Virtual Private Server account managed by a web hosting company (who are quite responsive to support questions).  I do successfully run other PHP applications.  Can you tell me what might be the configuration issues that would impact coppermine?

3) What do you mean by "simplified install page"? What do you expect us to remove from it?

Sorry, my mistake.  I meant simplified "index.php" page.  Since all of coppermine appears to work except the index page, I was thinking there might be some way to simplfy or comment out stuff in the index page to see what or where it is breaking down.

4) What "other" posting are you refering to?
Joachim

Sorry again, not sure what you mean here. I started a thread earlier on this problem (others have it too) and got no solution. See
http://forum.coppermine-gallery.net/index.php?topic=10275.0  This thread has a lot of info from me on the problem.

[Joachim Müller]

just a blind guess: do you have output compression turned on?

Joachim

P.S. merged your two threads which deal with the same issue.

[JMelhuish]

No, I don't think I have output compression on.  At least I did not explicitly create an ouput filter for Coppermine or any other application.  I will try and work out if there is any compression running in the server.

If you wish to view the problem, simply go to my test website for coppermine but try and visit a page other than index.php, for example  http://melhuish.org/cpg132/thumbnails.php?album=lastup

All other pages are displaying fine, it is only index.php that is causing a problem.

Also I created a user if you want to login:
username: test
password: t1e2m3p4

Thanks!
James

[Nibbler]

You do have gzip output encoding enabled and this is causing the problem, I was able to retrieve your index page using a manually created http header.

[JMelhuish]

A big thank you to everyone.  The problem was that I had zlib.output_compression = On in php.ini  Turning this off allowed proper parsing and output of index.php

I think this should be mentioned somewhere in the install documentation, or in the FAQ, or both.  I searched the forum and found reference to this problem. These other posts reference pretty much the same problem:
http://forum.coppermine-gallery.net/index.php?topic=4888.0
http://forum.coppermine-gallery.net/index.php?topic=1457.0
http://forum.coppermine-gallery.net/index.php?topic=1642.0
http://forum.coppermine-gallery.net/index.php?topic=9182.0
and a few others more recent that I can't find now.

I am somewhat confused as to whether the apache gzip compression of output (mod_deflate module) is different to the zlib compression.  I think I have the apache compression turned on, but am not sure (??), this is from httpd.conf:

# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
#
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

But I have not myself enabled compression, by the method in apache documentation (  SetOutputFilter DEFLATE : will enable compression for documents in the container where it is placed)  [ what is a container? ]

Also, I did some of my own debugging on index.php in the only way I know, cutting code.  I found that the binary junk was produced from code within the $elements = [/i] function on line 682.  If any of the following case functions were present, I got the binaries:

  case 'catlist':
  case 'alblist':
  case 'random':
  case 'lastup':

BUT, every other case allowed proper display of the index.php page [ and these other case functions included the flush() statements ].  I think this might have been caused by the presence of information (and uploaded photos) in categories list, album list, random, last uploaded; and the lack of information in the other cases (toprated, etc.).

If you cannot use zlib compression, please put that in the install documentation.  Also could I get an answer about whether one can use mod_deflate in apache for gzip output?  (Or maybe it is not really necessary?)  Thanks!

Thanks again everyone.  Hopefully I can get Coppermine working with PunBB now!

James

[kegobeer]

I have zlib.output_compression set to on and everything works great.  Look at output_handler; do you have it set to anything?  If you do, that's your problem: regarding zlib.output_compression, php.ini states...

output_handler must be empty if this is set 'On' !!!!

You can't have both set, it's an either/or situation.

My test box runs Apache 2.0.50, php 4.3.9.

[JMelhuish]

No, in fact in my php.ini, the output_handler is set to empty, i.e.

output_handler =

So that's not it.  Any other ideas?

James

[kegobeer]

In php.ini, what is your implicit_flush setting?

I've also attached my apache.conf and php.ini files (in txt format) for your review.  Maybe you can spot a difference that could be causing your issue.