I'm afraid to ask for an example of a 'long source', but
could you provide some details about the size of the code,
and what sort of results you're seeing?

PHP 4.1.0 with Apache 1.3.22 truncates sources I have also PHP 4.0.6 with Apache Advanced Extranet Server 1.3.20
that does not have the bug ./congfigure --with-mysql --with-apache=../apache-1.3.22 --enable-track-vars long sources only are truncated short display correctly

well for example 7141 bytes gets truncated while 3159 bytes does not

do you have any standard way of replying a bug I couldn't find one

It seems this is related to output control.

it depends on the setting of output buffering when it is off all is ok when it is set to a limited amount like 4096 the sources get truncated when on no browser can connect not even telnet

4.0.6 has the same problem

Apache 1.3.19 with PHP 4.1.0 has it also on the Windows platform

Duplicated on Linux/Apache 1.2.23 with PHP 4.2.0.

With output buffering enabled, Mozilla pops up 'document has no data', with output buffering disabled, the source is almost all viewable.  That is to say, the last two lines are missing, the generated html is truncated.

The source I'm trying to render is 2344 bytes long.

Disabling zlib.output_compression yields full source in Mozilla but both lynx and wget are still missing the end chunk (last two lines are truncated)

Setting output_buffering=0 allows Mozilla to get the full source every time.  Setting it to 1 breaks it every time. Setting it to 2+ yields random results.  Between no truncation and several lines of truncation (Mozilla).

The curious part of this is that lynx and wget always fetch the same number of bytes every time.

Setting output_buffering to anything over 16386 (which by the way is the magic number of bytes that wget/lynx fetch, breaks all attempts at fetching the source.  Note, the php script itself still performs fine.

This problem probably will not be fixed.

1) It does not worth the effort.
2) There is show_source()
3) phps does not work under certain encodings.

Use show_source() instead...

I made this report as Documentation problem to encourage use of show_source().

Someday, when ZendEngine became fully i18n, someone may care to fix phps.

After document is updated I'll take a look at output buffering code. (If there is problem here, it should be fixed) 

David, 
Did you tested with 4.2.0? 
What is your OS?
Please update Version and OS field, thanks.

As per my first post ;) ...

Yes, 4.2.0, and yes on Linux.  I'm not the original reporter, I can't update this bug's fields.

I have to ask why .phps won't be used.  It's -very- convenient and well established in the community.  What is as simple using show_source()?  At present all I had to do was make a symlink to my source with .phps as the extension.

Irrespective, my source is plain english, no special chars involved, etc.

Thanks for reply.

Here is why,

phps feature is implemented as Zend feature. Therefore, it does not work well with output bufffering, since output buffering is PHP feature. (some problems with output like you have, don't work with built in output callback functions, etc)

hilight_file (show_source or highlight_string) provides the same feature with much better way. If you are using apache and mod_rewrite, you can have script like

<?php
// If you need access control write here.
$filename = // Code to dicide file to show
$src = hilight_file($filename, TRUE); 

// Do what ever you need
// Add header/footer, translate encoding, etc

print $src;
?>

to show sources you want to hilight.
You don't even have to create symlinks and this method works with any configuration.

Refer to mod_rewrite manual how you can do that w/o 
creating files.

BTW, last time I checked, phps does not work with zlib.output_compression. I might be able to make phps
work under any configuration, but I don't think it
worth to do. (Patches are welcome, though)

Dillo (http://dillo.cipsga.org.br/) handles .phps files fine, though others (mozilla, ie) don't.

And as a user of .phps, I'd just like to venture the humble opinion that it's more secure and convenient in many cases to make a symlink than a security-conscious source viewer program.

Recategorized as feature-request, and status as wont-fix (otherwise you really want to tackle it, yohgaki, but that's why there's such a status, right? ;-)) during the qa-bughunt.