php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #14770 phps truncates long sources
Submitted: 2001-12-30 07:19 UTC Modified: 2002-07-02 17:04 UTC
Votes:6
Avg. Score:3.7 ± 1.1
Reproduced:6 of 6 (100.0%)
Same Version:1 (16.7%)
Same OS:1 (16.7%)
From: Shaggy_Pyce at yahoo dot com Assigned: yohgaki (profile)
Status: Wont fix Package: Feature/Change Request
PHP Version: 4.2.0 OS: Linux/Windows 98SE
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: Shaggy_Pyce at yahoo dot com
New email:
PHP Version: OS:

 

 [2001-12-30 07:19 UTC] Shaggy_Pyce at yahoo dot com
PHP 4.1.0 with Apache 1.3.22 truncates sources I have also PHP 4.0.6 with Apache 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-31 05:05 UTC] cardinal@php.net
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?
 [2002-01-02 06:58 UTC] Shaggy_Pyce at yahoo dot com
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
 [2002-01-02 14:42 UTC] yohgaki@php.net
It seems this is related to output control.
 [2002-01-05 07:21 UTC] Shaggy_Pyce at yahoo dot com
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
 [2002-03-10 01:10 UTC] Shaggy_Pyce at yahoo dot com
Apache 1.3.19 with PHP 4.1.0 has it also on the Windows platform
 [2002-04-25 17:27 UTC] david at blue-labs dot org
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.
 [2002-04-25 17:49 UTC] david at blue-labs dot org
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)
 [2002-04-25 17:59 UTC] david at blue-labs dot org
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.
 [2002-04-25 18:16 UTC] david at blue-labs dot org
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.
 [2002-04-25 19:20 UTC] yohgaki@php.net
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.


 [2002-04-25 19:29 UTC] yohgaki@php.net
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.

 [2002-04-25 22:46 UTC] david at blue-labs dot org
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.
 [2002-04-25 23:14 UTC] yohgaki@php.net
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)




 [2002-05-22 00:03 UTC] adamhooper at videotron dot ca
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.
 [2002-07-02 17:04 UTC] eru@php.net
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.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 05:01:29 2024 UTC