Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
On 13.11.2008, at 14:48, Arnaud Le Blanc wrote: Hi, Committed, thanks Christian :) apache2handler, apache2filter, apache, apache_hooks, cli and cgi SAPIs have been updated. The following SAPIs need to be updated in PHP_5_3 and HEAD: aolserver, continuity, litespeed, nsapi, caudium, phttpd, roxen. (I'm CC-ing known maintainers) More informations on the change can be found in the commit message: http://news.php.net/php.cvs/54228 err .. whats the status here? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
Still working on it, hadn't have enough time for it until now, I try to do it as soon as possible! - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2008 2:07 PM To: Arnaud Le Blanc Cc: Uwe Schindler; internals@lists.php.net; 'Christian Schmidt'; Alex Leigh; George Wang Subject: Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader() On 13.11.2008, at 14:48, Arnaud Le Blanc wrote: Hi, Committed, thanks Christian :) apache2handler, apache2filter, apache, apache_hooks, cli and cgi SAPIs have been updated. The following SAPIs need to be updated in PHP_5_3 and HEAD: aolserver, continuity, litespeed, nsapi, caudium, phttpd, roxen. (I'm CC-ing known maintainers) More informations on the change can be found in the commit message: http://news.php.net/php.cvs/54228 err .. whats the status here? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in interbase.c invalid BLOB ID
On 28.11.2008, at 06:15, Benjamin Schwarze wrote: Hi! As some other users recognized, there is a bug in the implementation of the function _php_ibase_quad_to_string. (imho since version 5.2.1) The line spprintf(result, BLOB_ID_LEN+1, 0x%0* LL_MASK x, 16, *(ISC_UINT64*)(void *) qd); doesnt work as estimated. The result stored inside qd isnt the value convertet from the string, but something else. Normally this should work, but it doesnt. One possible solution is, to change the line into spprintf(result, BLOB_ID_LEN+1, 0x%0*x%0*x, 8, qd.gds_quad_low, 8, qd.gds_quad_high); Of course, there might be a smarter way, but this solution worked for me. My system is a Fedora Core 8 64bit. is there a bug opened for this? if not please open one. also please add your patch regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with building PHP
Hi there, I spent many days tring to build PHP from source and now I found your new (and hidden???) site. I have new hope that I'll succesfuly build this beast. But... as you can seeI have problem. I download libraries from this link http://pecl2.php.net/downloads/php-windows-builds/php-libs/ from VC9 folder. Where I wrong? Thanx in advance, Goran Savkic (ex-programmer if you not help me) Creating library Release_TS\php_pdo_odbc.lib and object Release_TS\php_pdo_od bc.exp EXT pdo_odbc build complete cl.exe /D COMPILE_DL_PDO_SQLITE /D PDO_SQLITE_EXPORTS=1 /DSQLITE_THREA DSAFE=1 /Iext\pdo_sqlite/../sqlite3/libsqlite /Iext\pdo_sqlite /nologo /FD /I . /I main /I Zend /I TSRM /I ext /D _WINDOWS /D ZEND_WIN32=1 /D PHP_WIN32=1 /D WIN 32 /D _MBCS /wd4996 /D_USE_32BIT_TIME_T=1 /Zi /LD /MD /W3 /Ox /D NDebug /D NDE BUG /D ZEND_WIN32_FORCE_INLINE /GF /D ZEND_DEBUG=0 /D ZTS=1 /D FD_SETSIZE=256 /I ..\win32build\include /FoRelease_TS\ext\pdo_sqlite\ /FdRelease_TS\ext\pdo_sql ite\ /FpRelease_TS\ext\pdo_sqlite\ /FRRelease_TS\ext\pdo_sqlite\ /c ext\pdo_sqli te\pdo_sqlite.c ext\pdo_sqlite\sqlite_driver.c ext\pdo_sqlite\sqlite_statement.c pdo_sqlite.c sqlite_driver.c sqlite_statement.c Generating Code... rc /n /fo Release_TS\php_pdo_sqlite.dll.res /d FILE_DESCRIPTION=\SQLit e 3.x driver for PDO\ /d FILE_NAME=\php_pdo_sqlite.dll\ /d URL=\http://w ww.php.net\ /d INTERNAL_NAME=\PDO_SQLITE extension\ /d THANKS_GUYS=\Than ks to Wez Furlong\ win32\build\template.rc Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. Creating library Release_TS\php_pdo_sqlite.lib and object Release_TS\php_pdo_ sqlite.exp EXT pdo_sqlite build complete cl.exe /D COMPILE_DL_SOAP /D SOAP_EXPORTS=1 /nologo /FD /I . /I main / I Zend /I TSRM /I ext /D _WINDOWS /D ZEND_WIN32=1 /D PHP_WIN32=1 /D WIN32 /D _MB CS /wd4996 /D_USE_32BIT_TIME_T=1 /Zi /LD /MD /W3 /Ox /D NDebug /D NDEBUG /D ZE ND_WIN32_FORCE_INLINE /GF /D ZEND_DEBUG=0 /D ZTS=1 /D FD_SETSIZE=256 /I ..\win3 2build\include /FoRelease_TS\ext\soap\ /FdRelease_TS\ext\soap\ /FpRelease_TS\ex t\soap\ /FRRelease_TS\ext\soap\ /c ext\soap\php_encoding.c ext\soap\php_http.ce xt\soap\php_packet_soap.c ext\soap\php_schema.c ext\soap\php_sdl.c ext\soap\php_ xml.c ext\soap\soap.c php_encoding.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type ext\soap\php_encoding.c(2485) : warning C4018: '' : signed/unsigned mismatch ext\soap\php_encoding.c(2766) : warning C4146: unary minus operator applied to u nsigned type, result still unsigned php_http.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type php_packet_soap.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type php_schema.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type php_sdl.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type php_xml.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type soap.c C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\Ws2tcpip.h(502) : warning C 4142: benign redefinition of type Generating Code... rc /n /fo Release_TS\php_soap.dll.res /d FILE_DESCRIPTION=\SOAP\ /d FILE_NAME=\php_soap.dll\ /d URL=\http://www.php.net\; /d INTERNAL_NAME=\ SOAP extension\ /d THANKS_GUYS=\Thanks to Brad Lafountain, Shane Caraveo, D mitry Stogov\ win32\build\template.rc Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0 Copyright (C) Microsoft Corporation. All rights reserved. Creating library Release_TS\php_soap.lib and object Release_TS\php_soap.exp php_encoding.obj : error LNK2019: unresolved external symbol _xmlSearchNs refere nced in function _master_to_zval_int php_schema.obj : error LNK2001: unresolved external symbol _xmlSearchNs php_sdl.obj : error LNK2001: unresolved external symbol _xmlSearchNs php_xml.obj : error LNK2001: unresolved external symbol _xmlSearchNs php_encoding.obj : error LNK2019: unresolved external symbol _xmlFreeNode refere nced in function _to_zval_user php_xml.obj : error LNK2001: unresolved external symbol _xmlFreeNode soap.obj : error LNK2001: unresolved external symbol _xmlFreeNode php_encoding.obj : error LNK2019: unresolved external symbol _xmlBufferFree refe renced in function _to_zval_user php_encoding.obj : error LNK2019: unresolved external symbol _xmlBufferContent r eferenced in function _to_zval_user php_encoding.obj : error LNK2019: unresolved external symbol _xmlNodeDump refere nced in function _to_zval_user php_encoding.obj : error LNK2019: unresolved external symbol _xmlBufferCreate re ferenced in function _to_zval_user php_encoding.obj : error
Re: [PHP-DEV] Bug in interbase.c invalid BLOB ID
There is already a bug report: http://bugs.php.net/42089 My last comment contains the patch. And sorry for the false title of this thread. In real it is the file ibase_blobs.c. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
Just one question here:
When implementing this into NSAPI, I found the following problem:
NSAPI does not directly allows to remove all headers, you can only do this
step by step. So there are three possibilities to ship around this problem:
a) when SAPI_HEADER_DELETE_ALL is given, in header_handler, do the following
(using the sapi_header_struct given as last parameter):
zend_llist_apply(sapi_headers-headers, (llist_apply_func_t)
php_nsapi_remove_header TSRMLS_CC);
with:
static int php_nsapi_remove_header(sapi_header_struct *sapi_header
TSRMLS_DC)
{
char *header_name, *p;
nsapi_request_context *rc = (nsapi_request_context
*)SG(server_context);
header_name = nsapi_strdup(sapi_header-header);
if (p = strchr(header_name, ':')) *p = 0;
...
param_free(pblock_remove(header_name, rc-rq-srvhdrs));
nsapi_free(header_name);
return ZEND_HASH_APPLY_KEEP;
}
This would remove all headers, set by PHP. Headers embedded by the server
itself would not be deleted (e.g. Server: etc.)
b) Use some hack to get rid of all headers from the server's hashtable
(like apr_table_clear()). This would remove all headers and also some
important headers set by the server itself (like Server:, Chunked response
headers, etc). I am not sure if this would be good, in my opinion
SAPI_HEADER_DELETE_ALL should only remove headers set by PHP itself! What
does the other SAPI developers think, is it safe to remove apaches default
headers? I am not sure and tend to say: NO!
c) Completely ignore sapi_header_handler like in CGI and set the headers
later in sapi_send_headers() using the given struct with zend_llist_apply().
Then I do not have to take care of adding/removing headers, I set them to
Sun Webserver shortly before starting the response. Why the difference
between header_handler and send_headers? Is it ok to remove header_handler
(like in CGI) and simply feed all headers in send_headers? This would make
life for SAPI developers easier (also maybe in Apache). What is the idea to
respond after each header change?
What do you think?
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 2:07 PM
To: Arnaud Le Blanc
Cc: Uwe Schindler; internals@lists.php.net; 'Christian Schmidt'; Alex
Leigh; George Wang
Subject: Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set
usingheader()
On 13.11.2008, at 14:48, Arnaud Le Blanc wrote:
Hi,
Committed, thanks Christian :)
apache2handler, apache2filter, apache, apache_hooks, cli and cgi
SAPIs have
been updated.
The following SAPIs need to be updated in PHP_5_3 and HEAD:
aolserver, continuity, litespeed, nsapi, caudium, phttpd, roxen.
(I'm CC-ing
known maintainers)
More informations on the change can be found in the commit message:
http://news.php.net/php.cvs/54228
err .. whats the status here?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
Hi,
On Friday 28 November 2008 18:24:38 Uwe Schindler wrote:
Just one question here:
When implementing this into NSAPI, I found the following problem:
NSAPI does not directly allows to remove all headers, you can only do this
step by step. So there are three possibilities to ship around this problem:
a) when SAPI_HEADER_DELETE_ALL is given, in header_handler, do the following
(using the sapi_header_struct given as last parameter):
zend_llist_apply(sapi_headers-headers, (llist_apply_func_t)
php_nsapi_remove_header TSRMLS_CC);
with:
static int php_nsapi_remove_header(sapi_header_struct *sapi_header
TSRMLS_DC)
{
char *header_name, *p;
nsapi_request_context *rc = (nsapi_request_context
*)SG(server_context);
header_name = nsapi_strdup(sapi_header-header);
if (p = strchr(header_name, ':')) *p = 0;
...
param_free(pblock_remove(header_name, rc-rq-srvhdrs));
nsapi_free(header_name);
return ZEND_HASH_APPLY_KEEP;
}
This would remove all headers, set by PHP. Headers embedded by the server
itself would not be deleted (e.g. Server: etc.)
b) Use some hack to get rid of all headers from the server's hashtable
(like apr_table_clear()). This would remove all headers and also some
important headers set by the server itself (like Server:, Chunked response
headers, etc). I am not sure if this would be good, in my opinion
SAPI_HEADER_DELETE_ALL should only remove headers set by PHP itself! What
does the other SAPI developers think, is it safe to remove apaches default
headers? I am not sure and tend to say: NO!
c) Completely ignore sapi_header_handler like in CGI and set the headers
later in sapi_send_headers() using the given struct with zend_llist_apply().
Then I do not have to take care of adding/removing headers, I set them to
Sun Webserver shortly before starting the response. Why the difference
between header_handler and send_headers? Is it ok to remove header_handler
(like in CGI) and simply feed all headers in send_headers? This would make
life for SAPI developers easier (also maybe in Apache). What is the idea to
respond after each header change?
I believe that Apache does sets its headers just before sending them, so when
PHP deletes all headers in Apache's hashtable this does not removes Server,
Date, etc. If this is not the case for NSAPI, solution a) seems good, but
also allows to remove Date by setting it before ;)
One reason for having header_handler() and send_headers() is for example that
flush() does not sends headers explicitly, but lets the server send them based
on what header_handler() has set.
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apha3
Hi Lukas,
First of all, @all: http://wiki.php.net/rfc/rounding - I didn't have
time to update it yet but the basically nothing has changed except for
implementation details wrt. FPU precision. For FPU precision
explanations see (*).
Anyways, a few items from the top of my head that I know people were
talking about:
- rounding patch
I've split the patch in two parts:
(1) Make the Zend Engine always use double FPU precision on x87
platforms (creates zend_float.h, defines certain macros, uses those
macros in zend_strtod.c and zend_operators.c), include the correct
configure checks that detect the switching method. zend_float.h is
basically a copy of my xpfpa.h from (*) where I put in the research on
the behaviour of different platforms and compiler versions.
(2) Modify round() behaviour as described in the RFC (that also uses the
x87 FPU precision switch). The second part will only compile if the
first part was applied.
It is basically the same patch as I have already posted to this list -
just with a few cleanups. Here are the basic changes to the previous
patch versions:
a) Added Zend/tests/fpu_prec_001.phpt which tests for double precision.
With single, double-extended or quad precision, it will fail.
b) @Macrus: I've thought about your points wrt. cross-compilation and
I am now certain that if the configure test scripts compile link,
the code will also work - so there is no need to execute it. I've
thus changed AC_TRY_RUN to AC_LINK_IFELSE.
c) Added
ext/standard/tests/math/round_{prerounding,large_exp,modes}.phpt
which check for the new behaviour of round().
d) Some minor cleanups to the FPU macros and configure checks.
Anyway, here are the patches, please remember that 1+3 test files are
added with the patches:
PHP 5.3, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-fpu.patch
PHP 5.3, round() behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-round.patch
PHP 6, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-fpu.patch
PHP 6, round() behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-round.patch
(*) http://www.christian-seiler.de/projekte/fpmath/
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
