ID:               12022
 Comment by:       ash27_75 at yahoo dot com
 Reported By:      noisefactor at netscape dot net
 Status:           Closed
 Bug Type:         Output Control
 Operating System: linux
 PHP Version:      4.0.2
 New Comment:

i have a file .dat which is 3.5 GiG .when im trying to gzip the file
i'm getting an error as 'unknown error'.
Does the size of the file matters for gzip command,if yes suggest me a
better way to zip a big file.
How does compress differ from gzip.
thanks
Ashok


Previous Comments:
------------------------------------------------------------------------

[2003-09-01 02:52:02] learn at university dot com

>From what I have read, the problem is in your theory.
Do you understand what the difference between a browser window and
output to screen is?
This will go a long way in identifying why and when you should use
certain approaches.
Just because you can do it in one language doesn't mean it's a correct
method.

------------------------------------------------------------------------

[2001-09-10 17:08:39] [EMAIL PROTECTED]

First update to more recent version before submiting any 
bug reports. 4.0.2 is just too old.

--Jani


------------------------------------------------------------------------

[2001-09-09 15:07:16] noisefactor at netscape dot net

incidently, i've used telnet to port 80 to 
monitor the output of the .php script that feeds 
the applet, and it's clear that the problem is
on the php end.  having said that, i have no
idea if this is normal 4.0.2 behavior or if it
will not be reproduced on other systems.

results of these tests are below...

#
# First using the php://stdout technique,
# exactly as suggested by rasmus
#
telnet artcontext.org 80 
Trying 160.79.162.111...
Connected to artcontext.org.
Escape character is '^]'.
GET /act/01/test/makeencoded.php HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 09 Sep 2001 19:21:14 GMT
Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2
X-Powered-By: PHP/4.0.2
Connection: close
Content-Type: application/x-gzip

Connection closed by foreign host.
#
# connection closes, no output
#

#
# next using the readfile technique --
# 
telnet artcontext.org 80 
Trying 160.79.162.111...
Connected to artcontext.org.
Escape character is '^]'.
GET /act/01/test/makeencoded.php HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 09 Sep 2001 19:21:31 GMT
Server: Apache/1.3.12 (Unix) ApacheJServ/1.1.2 PHP/4.0.2
X-Powered-By: PHP/4.0.2
Connection: close
Content-Type: application/x-gzip

(some garbage compression text appears here)

------------------------------------------------------------------------

[2001-09-09 14:57:45] noisefactor at netscape dot net

in order to demonstrate the problem that i'm 
experiencing, i've made a small tarball with 
rasmus's suggestion, and the java applet (simplified)
code that accepts the file-based gzip data, but 
doesn't work with the technique rasmus suggests.

since i'm using 4.0.2, i could only try one of his
suggestions (there was no gzencode in 4.0.2).

andy

http://artcontext.org/act/01/test.gz

PS successful execution of the applet simply dumps
"Hello World" into the monitor/console.

------------------------------------------------------------------------

[2001-09-08 20:34:59] [EMAIL PROTECTED]

What exactly is the issue here?  Why are you trying to open up stdout? 
You can write gzip data directly without doing that.  For example:

<?
        Header("Content-type: application/x-gzip");
        echo gzencode("Hello World");
?>

This works just fine.  The headers are uncompressed, the content is
compressed.  I don't see a bug here.  stdout only makes sense when
running from the command line.  Which also works just fine, by the
way:

<?
        Header("Content-type: application/x-gzip");
        $fp = gzopen("php://stdout", "w");
        gzputs ($fp, "Hello World");
?>

which when run from the command line produces:

X-Powered-By: PHP/4.0.7-dev
Content-type: application/x-gzip

óHÍÉÉÏ/ÊIV±J

Again, uncompressed headers, compressed data.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/12022

-- 
Edit this bug report at http://bugs.php.net/?id=12022&edit=1

Reply via email to