#23975 [Com]: dba_open locking error with ndbm/db2/db3

2003-08-23 Thread fabio_heller at yahoo dot it 
 ID:   23975
 Comment by:   fabio_heller at yahoo dot it
 Reported By:  rhalstenbach at t-online dot de
 Status:   Assigned
 Bug Type: DBM/DBA related
 Operating System: win32 only
 PHP Version:  4.3.3RC4-dev
 Assigned To:  helly
 New Comment:

curtois wrote

"The bug I submitted (25115) was declared "duplicate" with this one."

Same thing happened to me (25090) as in this post the precise error
occurred (Driver initialization failed for...) isnt't specified so the
search engine doesn't help in finding it.

Anyway the problem is still present in cvs version for WIN and
specially it isn't possibile to use "c" mode to create a  new db.


Previous Comments:


[2003-08-19 04:48:42] courtois at nouvo dot com

The bug I submitted (25115) was declared "duplicate" with this one.

I experience the problem only when I try to open a file which is not in
the current directory.

My 2 cents



[2003-06-15 08:56:32] [EMAIL PROTECTED]

Seems to be a windows only problem. The bug is fixed for *nix.



[2003-06-15 08:43:41] rhalstenbach at t-online dot de

Re-Opened. It still does not work, tested with snapshot "Built On: Jun
15, 2003 12:30 GMT".

Sent an email to marcus dot boerger at post dot rwth-aachen dot de (he
asked me to check out the snapshot and to run a test).



[2003-06-12 15:01:24] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Maybe this applies to dbm, too. However the problem is solved in a
generic way.



[2003-06-10 05:19:49] adam at saki dot com dot au

This is actually because the locking will prematurely create an empty
file, causing the VCWD_STAT command in dba_db3.c to return 0, resulting
in the wrong parameters to db_open.

This can be verified by putting a stat command after the lock detection
code and before the call to open (line 590 in ext/dba/dba.c).



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/23975

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

#21354 [Opn->WFx]: instantiation class reflection

2003-08-23 Thread andrey 
 ID:   21354
 Updated by:   [EMAIL PROTECTED]
 Reported By:  proman at dcc dot uchile dot cl
-Status:   Open
+Status:   Wont fix
 Bug Type: Feature/Change Request
 Operating System: suse 8.0
 PHP Version:  4.3.0
 New Comment:

This was changed for good IMO.


Previous Comments:


[2003-01-02 16:21:11] proman at dcc dot uchile dot cl

 In the version 4.3 it is not posible to 
change $this pointer to another class. 
That is a serious drawback, because the 
language loose one of the powerfull 
reflection method that is dificult to found 
in others language.  
Posibly i will continue to use old versions 
instead of the new one. 




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

#22469 [Opn->Bgs]: alias for mysql_result($res, 0)

2003-08-23 Thread andrey 
 ID:   22469
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Amiel dot Martin at wwu dot edu
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.2.3
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You may use array_pop to achieve this :




Previous Comments:


[2003-02-27 23:26:03] Amiel dot Martin at wwu dot edu

I use:

$res = mysql_query("SELECT one_column FROM table")
  or die("blah");
$var = mysql_result($res,0);

VERY often.
I am requesting a pop-like function for a mysql result;

so that:

mysql> SELECT col_one, col_two FROM table;
-
| col_one | col_two |
|-|-|
| res one | res two |
| res thr | res fou |
|---|



would print:
res one
res two
res thr
res fou


thanks much,

Amiel




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

#25204 [Bgs->Opn]: ETag Responce Header Ignored

2003-08-23 Thread support at inmarket dot lviv dot ua 
 ID:   25204
 User updated by:  support at inmarket dot lviv dot ua
 Reported By:  support at inmarket dot lviv dot ua
-Status:   Bogus
+Status:   Open
 Bug Type: CGI related
 Operating System: win32
 PHP Version:  4.3.2
 New Comment:

And whose problem is this: Apache or PHP?


Previous Comments:


[2003-08-23 11:36:57] support at inmarket dot lviv dot ua

And what if some stupid hosting provider has PHP thru CGI??? Like mine
does! And, after all, why does this happen? This must be a trivial task
to fix?



[2003-08-22 19:57:50] [EMAIL PROTECTED]

This is not really Apache related but CGI. If you were really using the
apache module, this would propably work just fine.
See: http://www.mnot.net/cgi_buffer/




[2003-08-22 09:52:04] support at inmarket dot lviv dot ua

The test script simply sends "ETag" header via header("ETag:
0-1234-12345678");

My Apache is win32 1.3.28, PHP 4.3.2 CGI - default configuration



[2003-08-22 03:21:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Also, what is in your script?
Which apache version? 
How did you configure PHP?




[2003-08-22 02:47:54] support at inmarket dot lviv dot ua

Description:

Actually I posted this bug to Apache, but they said this is PHP bug.

I noticed that ETag responce header from PHP script is simply ignored.
If there comes a request with "If-None-Match" and the script responds
with "ETag" that matches it, the server responds with "200 OK" status.
When checked with static content, Apache has no problem responding with
"304 Not Modified". 
There is no problem when script responds with "Last-Modified", and the
server then ends up with "304 Not Modified". 

What I got from Apache bug report system:

This is a php bug. The handler (read: PHP) is responsible for calling
ap_meets_conditions at the proper place (i.e. before sending the
content) or
doing the evaluation that takes place there itself.

Please address this issue to the php bug database.

Regards,
Dennis

Reproduce code:
---
Request:
GET /temp/etag.php HTTP/1.1
If-None-Match: "0-1234-12345678"

Responce:
HTTP/1.1 200 OK  -- should be 304 as for static content is
ETag: "0-1234-12345678"

Whereas using time-related headers:
Request:
GET /temp/etag.php HTTP/1.1
If-Modified-Since: Thu, 31 Jul 2003 19:12:11 GMT

Responce:
HTTP/1.1 304 Not Modified  -- as expected
Last-Modified: Thu, 31 Jul 2003 19:12:11 GMT

Also combining two kinds of headers is useless:
Request:
GET /temp/etag.php HTTP/1.1
If-None-Match: "0-1234-12345678"
If-Modified-Since: Thu, 31 Jul 2003 19:12:11 GMT

Responce:
HTTP/1.1 200 OK  -- Note this happens despite Last-Modified!
ETag: "0-1234-12345678"
Last-Modified: Thu, 31 Jul 2003 19:12:11 GMT







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

#25204 [Bgs]: ETag Responce Header Ignored

2003-08-23 Thread support at inmarket dot lviv dot ua 
 ID:   25204
 User updated by:  support at inmarket dot lviv dot ua
 Reported By:  support at inmarket dot lviv dot ua
 Status:   Bogus
 Bug Type: CGI related
 Operating System: win32
 PHP Version:  4.3.2
 New Comment:

And what if some stupid hosting provider has PHP thru CGI??? Like mine
does! And, after all, why does this happen? This must be a trivial task
to fix?


Previous Comments:


[2003-08-22 19:57:50] [EMAIL PROTECTED]

This is not really Apache related but CGI. If you were really using the
apache module, this would propably work just fine.
See: http://www.mnot.net/cgi_buffer/




[2003-08-22 09:52:04] support at inmarket dot lviv dot ua

The test script simply sends "ETag" header via header("ETag:
0-1234-12345678");

My Apache is win32 1.3.28, PHP 4.3.2 CGI - default configuration



[2003-08-22 03:21:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Also, what is in your script?
Which apache version? 
How did you configure PHP?




[2003-08-22 02:47:54] support at inmarket dot lviv dot ua

Description:

Actually I posted this bug to Apache, but they said this is PHP bug.

I noticed that ETag responce header from PHP script is simply ignored.
If there comes a request with "If-None-Match" and the script responds
with "ETag" that matches it, the server responds with "200 OK" status.
When checked with static content, Apache has no problem responding with
"304 Not Modified". 
There is no problem when script responds with "Last-Modified", and the
server then ends up with "304 Not Modified". 

What I got from Apache bug report system:

This is a php bug. The handler (read: PHP) is responsible for calling
ap_meets_conditions at the proper place (i.e. before sending the
content) or
doing the evaluation that takes place there itself.

Please address this issue to the php bug database.

Regards,
Dennis

Reproduce code:
---
Request:
GET /temp/etag.php HTTP/1.1
If-None-Match: "0-1234-12345678"

Responce:
HTTP/1.1 200 OK  -- should be 304 as for static content is
ETag: "0-1234-12345678"

Whereas using time-related headers:
Request:
GET /temp/etag.php HTTP/1.1
If-Modified-Since: Thu, 31 Jul 2003 19:12:11 GMT

Responce:
HTTP/1.1 304 Not Modified  -- as expected
Last-Modified: Thu, 31 Jul 2003 19:12:11 GMT

Also combining two kinds of headers is useless:
Request:
GET /temp/etag.php HTTP/1.1
If-None-Match: "0-1234-12345678"
If-Modified-Since: Thu, 31 Jul 2003 19:12:11 GMT

Responce:
HTTP/1.1 200 OK  -- Note this happens despite Last-Modified!
ETag: "0-1234-12345678"
Last-Modified: Thu, 31 Jul 2003 19:12:11 GMT







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

#25220 [NEW]: Staticaly called members can access $this

2003-08-23 Thread php at koert dot bitfactory dot nl 
From: php at koert dot bitfactory dot nl
Operating system: Cygwin/win2k
PHP version:  5CVS-2003-08-23 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description:  Staticaly called members can access $this

Description:

If a static method is called from an objectcontext, $this is accessible
from that objectcontext.
$this should be out of scop in the static method...

Reproduce code:
---
class static_class {
   function static_func() { echo $this->variable;  }
}

class testclass {
   function func() { static_class::static_func(); }
}
$x = new testclass();
$x->func();




Expected result:


Fatal error:  Using $this when not in object context in
[filename] on line 2

Actual result:
--
No output (thus no error)

-- 
Edit bug report at http://bugs.php.net/?id=25220&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25220&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25220&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25220&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25220&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25220&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25220&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25220&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25220&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25220&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25220&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25220&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25220&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25220&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25220&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25220&r=gnused

#25058 [Com]: make install fails using with-apxs2

2003-08-23 Thread php at hottub dot ca 
 ID:   25058
 Comment by:   php at hottub dot ca
 Reported By:  carlo dot mosca at eurostar dot co dot uk
 Status:   Open
 Bug Type: Apache2 related
 Operating System: AIX 5.2
 PHP Version:  4.3.3RC4-dev
 New Comment:

Just to confirm, I have the same issue on AIX 5.1. ML4 
using the 'C for AIX v6' compiler with 4.3.3RC4.


Previous Comments:


[2003-08-15 07:30:49] carlo dot mosca at eurostar dot co dot uk

I still get the same error off make install:

Installing PHP SAPI module:   apache2handler   
  
/elgar/local/apache2/build/instdso.sh
SH_LIBTOOL='/elgar/local/apache2/build/libtool' libphp4.la
/elgar/local/apache2/modules 
rm -f /elgar/local/apache2/modules/libphp4.so  
  
/elgar/local/apache2/build/libtool --mode=install cp libphp4.la
/elgar/local/apache2/modules/ 
cp .libs/libphp4.a /elgar/local/apache2/modules/libphp4.a  
  
cp .libs/libphp4.lai /elgar/local/apache2/modules/libphp4.la   
  
libtool: install: warning: remember to run `libtool --finish
/elgar/devel/user/carlo/local/php4-STABLE-200308121530/libs' 
chmod 755 /elgar/local/apache2/modules/libphp4.so  
  
chmod: /elgar/local/apache2/modules/libphp4.so: A file or directory in
the path name does not exist.  
apxs:Error: Command failed with rc=65536   
  
.  
  
make: 1254-004 The error code from the last command is 1.  
  
   
  
   
  
Stop.  
  
2.360u 3.070s 0:12.30 44.1% 517+671k 0+0io 1251pf+0w   
  
CRM php4-STABLE-200308121530 -> ls -l libs/
  
total 9872 
  
-rw-r--r--   1 carlodevel   5044390 Aug 15 13:28 libphp4.a 
  
-rw-r--r--   1 carlodevel   723 Aug 15 13:28 libphp4.la
  
CRM php4-STABLE-200308121530 -> ls -l .libs/   
  
total 19624
  
-rw-r--r--   1 carlodevel   5044390 Aug 15 13:28 libphp4.a 
  
-rw-r--r--   1 carlodevel 26411 Aug 15 13:28 libphp4.exp   
  
lrwxrwxrwx   1 carlodevel13 Aug 15 13:28 libphp4.la ->
../libphp4.la  
-rw-r--r--   1 carlodevel   723 Aug 15 13:28 libphp4.lai   
  
-rwxr-xr-x   1 carlodevel   4961410 Aug 15 13:28 libphp4.so



[2003-08-15 07:20:30] [EMAIL PROTECTED]

Now, if you do 'make install', does it copy the correct libphp4.so in
place?




[2003-08-14 06:16:35] carlo dot mosca at eurostar dot co dot uk

Thanks, that seems to work:


Build complete.
   
(It is safe to ignore warnings about tempnam and tmpnam).  
   
   
   
80.030u 26.400s 2:10.45 81.5%   2200+1516k 0+0io 1479pf+0w 
   
CRM php4-STABLE-200308121530 -> ls -l libs 
   
total 9872 
   
-rw-r--r--   1 carlodevel   5044390 Aug 14 12:13 libphp4.a 
   
-rw-r--r--   1 carlodevel   723 Aug 14 12:13 libphp4.la

#25211 [Opn]: 'with-zlib' or 'with-bz2' causes 'redeclaration' of php_image_type_to_mime_type

2003-08-23 Thread php at hottub dot ca 
 ID:   25211
 User updated by:  php at hottub dot ca
 Reported By:  php at hottub dot ca
 Status:   Open
 Bug Type: Compile Failure
 Operating System: AIX 5.1 ML4
 PHP Version:  4.3.3RC4
 New Comment:

When I added the remainder of the configure options, 
the error occured again, despite the fact that the 
definitions are the same in both places.  Apparently 
the AIX compiler throws 'unsigned' in front of 'char' 
in header files.

When I edited both php_image.h and image.c to match 
each other (simply 'char'), I got a successful compile.  
Tests have been submitted to the QA site.

On a previous compile attempt, setting both definitions 
to 'const char' resulted in the same error again.  I 
will attempt to determine if this is a compiler issue 
for which there is a fix.


Previous Comments:


[2003-08-22 22:46:13] php at hottub dot ca

Removing 'const' from line 60 of ext/standard/
php_image.c allowed a clean compile -- make test will 
be submitted to list after additional configure flags 
have been added.



[2003-08-22 13:51:15] [EMAIL PROTECTED]

The declarations are exactly the same but maybe the compiler you use
doesn't understand const in return types. So please remove const from
the return type in both .c and .h file and tell me if that helps. If it
doesn't we need to find out why your compiler thinks the return type is
'unsigned char'.



[2003-08-22 10:15:44] php at hottub dot ca

Description:

Trying to compile 4.3.3RC4 on AIX 5.1 ML4 using IBM 
Visual Age C version 6.0 (cc).

PHP compiles properly with other options without issue, 
but when issuing configure with the --with-zlib and --
with-bz2 options, compilation fails.  Here is the 
command being executed:

cc  -Iext/standard/ -I/build/php-4.3.3RC4/ext/standard/ 
-DPHP_ATOM_INC -I/build/php-4.3.3RC4/include -I/build/
php-4.3.3RC4/main -I/build/php-4.3.3RC4 -I/build/php-
4.3.3RC4/Zend -I/usr/local/include -I/build/php-
4.3.3RC4/ext/xml/expat  -I/build/php-4.3.3RC4/TSRM  -g  
-c /build/php-4.3.3RC4/ext/standard/image.c -o ext/
standard/image.o  && echo > ext/standard/image.lo

And the error output:

"/build/php-4.3.3RC4/ext/standard/image.c", line 
1029.21: 1506-343 (S) Redeclaration of 
php_image_type_to_mime_type differs from previous 
declaration on line 60 of "/build/php-4.3.3RC4/ext/
standard/php_image.h".
"/build/php-4.3.3RC4/ext/standard/image.c", line 
1029.21: 1506-050 (I) Return type "unsigned char*" in 
redeclaration is not compatible with the previous 
return type "const unsigned char*".
make: *** [ext/standard/image.lo] Error 1

The system does not have mysql installed (IBM's DB2 is 
installed, but not enabled as a configuration option).  
There are also a number of warnings during compilation 
that all relate to mysql.h:

"/build/php-4.3.3RC4/ext/mysql/libmysql/mysql.h", line 
181.14: 1506-731 (W) The '_Export' keyword is not 
supported on the target platform.  The keyword is 
ignored.

This is the output from configure when the options are 
enabled:

00Configuring extensions00
checking for ZLIB support... yes
checking if the location of ZLIB install directory is 
defined... no
checking for gzgets in -lz... yes
checking whether to enable bc style precision math 
functions... no
checking for BZip2 support... yes
checking for BZip2 in default path... found in /usr
checking for BZ2_bzerror in -lbz2... yes

I can make a shell account available for the assignee 
to test themselves.

-JD.






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

#25218 [NEW]: PHP sends back invalid deflate data

2003-08-23 Thread amb at gedanken dot demon dot co dot uk 
From: amb at gedanken dot demon dot co dot uk
Operating system: 
PHP version:  4CVS-2003-08-23 (stable)
PHP Bug Type: Zlib Related
Bug description:  PHP sends back invalid deflate data

Description:

When PHP sends back data using the deflate method it incorrectly puts a
gzip style header before it.

I sent this request

GET / HTTP/1.0
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020623
Debian/1.2.5-0.woody.1
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Host: bugs.php.net
Connection: close
Accept-Encoding: x-deflate; q=0.9, deflate; q=0.9, identity; q=0.1

to bugs.php.net and got this reply header

HTTP/1.1 200 OK

Date: Sat, 23 Aug 2003 11:00:34 GMT

Server: Apache/1.3.27 (Unix) PHP/4.3.0

X-Powered-By: PHP/4.3.0

Content-Encoding: deflate

Vary: Accept-Encoding

Connection: close

Content-Type: text/html



with this data (converted to hex format by 'od -x')

000 8b1f 0008   0300 9c78 58cc 6fdd
020 36db 7f10 feae 038a b587 892f 2765 b643

The first 10 bytes are a valid gzip header (RFC1952), the following 2
bytes are a valid zlib header (RFC1950), the following bytes are valid
deflate data (RFC1951).  The first 10 bytes should not be sent.



-- 
Edit bug report at http://bugs.php.net/?id=25218&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25218&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25218&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25218&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25218&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25218&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25218&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25218&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25218&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25218&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25218&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25218&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25218&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25218&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25218&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25218&r=gnused

#25175 [Bgs]: session.use_trans_sid causes ob_get_length() to return incorrect value

2003-08-23 Thread phpbug at paypc dot com 
 ID:   25175
 User updated by:  phpbug at paypc dot com
 Reported By:  phpbug at paypc dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux 2.4
 PHP Version:  4.3.2
 New Comment:

ARGH... I had just rebuilt PHP (from the snapshot) and Apache the
problem still exists, though Moriyoshi-san pretty much pre-confirmed it
- I should have checked back here before embarking on a web-server
rebuild.  No worries.

When I have trans_sid enabled, the discrepancy crops up again, but you
knew that.

I have not plumbed the depths of Zend and the output buffering part of
PHP, but I'm surprised that this URL rewriting occurs at a level
"higher" than that which obtaining the length of that buffer to be sent
can be determined.

I can understand the issues with the gzhandler readily enough - that's
a "final pass" process which takes the entire output and compresses it
prior to its flight to the client.

If the gzhandler breaks trans_sid (or vice-versa), then I suspect
someone make a bizarre design decision about where these various parts
need to fit together.

Transformation passes like trans_sid should be made before transport
passes (like gzhandler) and functions which determine buffer length get
at things.  

I would like to think that this is NOT a Bogus bug, but a bug whose fix
is at least in the pipeline to be addressed.  While it's easier to
understand how the gzhandler problems would be an especially hard case
to resolve, the ob_get_length() one shouldn't be.  

Or is the problem one where the URL rewriting happens while the data is
actually IN-FLIGHT to the web-browser, after a possible response from
the browser *AFTER* the header has been sent, but before the content?

If the PHP team intends to never address this as a decision of policy,
then retire this bug and place warnings into the documentation and FAQ.
 

But if you intend to resolve it, I would think it retains some value to
leave it as an open issue for future (and possibly unspecified) future
resolution.

Apollyon


Previous Comments:


[2003-08-22 13:48:47] [EMAIL PROTECTED]

Technically, this is not a bug. Please see the following description.

trans-sid (aka URL rewriter) utilises output buffering facility and it
virtually works as a top level output buffer handler in the hanlder
stack. Thus ob_get_length() might not reflect the actual length of the
content being sent to the user-agent because trans-sid handler
automatically rewrites all URL referrers of the tags that are specified
by url_rewriter.tags in your php.ini so they contains session
identifiers if the content includes any one of those tags. So, in any
case ob_get_length() returns the size of the intact content, on which
no URL transformation is applied yet. The same thing applies to
zlib.output_compression.

Then let me mark this PR bogus since this is not a bug in PHP. But this
behaviour is rather confusing and will be addressed in the future
versions.

BTW, how on earth did you know I'm Japanese? :)



[2003-08-21 19:05:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip






[2003-08-21 04:33:50] phpbug at paypc dot com

*ARGH* I hate "thinkoes" -- it should be obvious from context (and
perusing my phpconfig) that I've TURNED OFF enable_trans_sid, not
turned it on.

Upon re-reading my posting (naturally AFTER I'd hit submit), I noted
the think-o.

My apologies.  

=Apollyon=



[2003-08-21 04:31:10] phpbug at paypc dot com

OK, let me put forth some declarations so we're talking apples and
apples.

My test method:

echo -e "GET /legal/tester.php HTTP/1.1\r\nHost: 127.0.0.1\r\n" | nc
127.0.0.1 80 > dump

I wish to eliminate any possible "post-processing" or
browser-variations.

IE: "nc" is netcat, a commonly available network tool.

OK, onto the results of my tests.

I copied and pasted sniper's code *EXACTLY* as presented, with
whitespaces and line spacing as entered.  I obtained identical results
with both lynx and my netcat method, though lynx probably doesn't
support HTTP/1.1 because there was an additional header.

With Lynx Version 2.8.3rel.1:

HTTP/1.1 200 OK
Date: Thu, 21 Aug 2003 09:10:16 GMT
Server: Apache/1.3.27 Ben-SSL/1.48
Connection-Type: Keep-Alive
Content-Length: 4
Connection: close   < Additional header
Content-Type: text/html

With netcat:

HTTP/1.1 200 OK
Date: Thu, 21 Aug 2003 09:10:55 GMT
Server: Apache/1.3.27 Ben-SSL/1.48
Connection-Type: Keep-Alive
Content-Length: 4
Content-Type: text/html

In comparing the actual bytes sent over the wire against the advertised
content-length, the

#25217 [NEW]: calling ob_gzhandler after modified buffer in ob handler, return origin buffer

2003-08-23 Thread Xuefer at 21cn dot com 
From: Xuefer at 21cn dot com
Operating system: win
PHP version:  4.3.3RC4
PHP Bug Type: Output Control
Bug description:  calling ob_gzhandler after modified buffer in ob handler, return 
origin buffer

Description:

only when client do not support compressing
save the below sample as: ob_gzhandler.phpt
and: make test

--TEST--
ob_gzhandler
--POST--
--GET--
--FILE--

--EXPECT--
456


=
FAILED TEST SUMMARY
-
ob_gzhandler [test/ob_handler.phpt]

actual output is 123, not 456


-- 
Edit bug report at http://bugs.php.net/?id=25217&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25217&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25217&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25217&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25217&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25217&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25217&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25217&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25217&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25217&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25217&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25217&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25217&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25217&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25217&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25217&r=gnused