changelog Wed Sep 8 20:34:42 2004 EDT
Modified files:
/php-srcChangeLog
Log:
ChangeLog update
http://cvs.php.net/diff.php/php-src/ChangeLog?r1=1.1740r2=1.1741ty=u
Index: php-src/ChangeLog
diff -u php-src/ChangeLog:1.1740 php-src/ChangeLog:1.1741
---
On Wed, 8 Sep 2004, Dmitry Stogov wrote:
Hi,
I should make a decision.
Can anybody point me to some utf-8 specification document?
http://www.unicode.org/faq/utf_bom.html#37
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
section 3.9, which proves that Rob is right and I was wrong for
rasmus Wed Sep 8 04:26:50 2004 EDT
Modified files:
/CVSROOTavail
Log:
karma for new accounts
http://cvs.php.net/diff.php/CVSROOT/avail?r1=1.903r2=1.904ty=u
Index: CVSROOT/avail
diff -u CVSROOT/avail:1.903 CVSROOT/avail:1.904
--- CVSROOT/avail:1.903 Thu
OK. I willn't add 6-bytes characters suppport.
You are right. The proper place for this function is ext/libxml.
I will glad to use it, if somebody will implement this function there.
Thanks. Dmitry.
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
That you. At least I know I'm still borderline and havent gone completely
insane.
It was changed in RFC 3629
It should probably be added in ext/libxml as libxml 2.6.13 (and it looks
like .12 as well) are broken badly here when a bug fix was done in the
function. Previous versions have a bug with
rrichards Wed Sep 8 06:16:58 2004 EDT
Modified files: (Branch: PHP_5_0)
/php-src/ext/libxml libxml.c php_libxml.h
Log:
MFH: implement php_libxml_xmlCheckUTF8
- workaround for = libxml2-2.6.13 function
Hello Sara :)
This morning I've started testing this new feature and I've found some bugs:
* it is segfaulting on redirects
* the chunk decoding algorithm isn't working well. Just run a diff in thw
output of both HTTP/1.0 and 1.1.
The only thing I can help is with backtraces:
* GDB:
Well well well. A basic HTTP client such as PHP does not
gain anything from supporting HTTP/1.1. Until the time this
feature is proven to be stable (especially the dechunking is
not always easy to do correctly and reliably in C), the code
should live outside of the mainstream
Well well well. A basic HTTP client such as PHP does not
gain anything from supporting HTTP/1.1. Until the time this
feature is proven to be stable (especially the dechunking is
not always easy to do correctly and reliably in C), the code
should live outside of the mainstream
HTTP/1.1 supports compressing, which is good to save bandwidth.
As does HTTP/1.0. Refer to RFC 1945, section 3.5 Content
Codings.
As the code is only in HEAD, there is no real problem, because untill PHP 5.1
goes out, I'll test this extensively :)
That is quite optimistic.
If
OK, so please #if it with libxml2 version number once it is clear what the
next version is.
Thanks,
Andi
At 09:17 AM 9/8/2004 +0400, Dmitry Stogov wrote:
The bug is fixed in libxml2 CVS HEAD, but it exists in latest stable
version.
Dmitry.
-Original Message-
From: Andi Gutmans
rrichards Wed Sep 8 12:54:17 2004 EDT
Modified files:
/php-src/ext/xslphp_xsl.c php_xsl.h xsltprocessor.c
Log:
fix issue with multiple xsl objects using registerPHPfunctions
- also fixes threading issue
rrichards Wed Sep 8 12:54:53 2004 EDT
Modified files: (Branch: PHP_5_0)
/php-src/ext/xslphp_xsl.c php_xsl.h xsltprocessor.c
Log:
MHF: fix issue with multiple xsl objects using registerPHPfunctions
- also fixes threading issue
This morning I've started testing this new feature and I've found some
bugs:
* it is segfaulting on redirects
I'll just bet I know why too
The way the http:// wrapper is built, any redirects would be prone to
stacking multiple filters on top of each other. There's two things to
address
Sascha Schumann wrote:
HTTP/1.1 supports compressing, which is good to save bandwidth.
As does HTTP/1.0. Refer to RFC 1945, section 3.5 Content
Codings.
As the code is only in HEAD, there is no real problem, because untill
PHP 5.1 goes out, I'll test this extensively :)
That is
pollita Wed Sep 8 14:42:15 2004 EDT
Modified files:
/php-src/main/streams streams.c
Log:
Handle maxlen when stream can't be mmaped
http://cvs.php.net/diff.php/php-src/main/streams/streams.c?r1=1.62r2=1.63ty=u
Index: php-src/main/streams/streams.c
diff -u
On Wed, 8 Sep 2004, Andi Gutmans wrote:
OK, so please #if it with libxml2 version number once it is clear what the
next version is.
Rob already did this in the core libxml stuff, he made a macro that
redirects everything to our own copy of the function.
Derick
--
Derick Rethans
pollita Wed Sep 8 14:45:05 2004 EDT
Modified files: (Branch: PHP_5_0)
/php-src/main/streams streams.c
Log:
MFH (r.163) Handle maxlen when stream can't be mmaped
http://cvs.php.net/diff.php/php-src/main/streams/streams.c?r1=1.61.2.1r2=1.61.2.2ty=u
Index:
Sacha-
I can appreciate that there is a limited potential need for PHP to support
chunked encoding right-now, however this is one step in a larger process
to support keep-alives and issuing multiple requests over a single
http/https session. I'd like to work on the issues raised by Nuno:
I can appreciate that there is a limited potential need for PHP to support
chunked encoding right-now, however this is one step in a larger process
I suggest you complete the larger process of cloning curl and
resubmit your stable changes then for review.
- Sascha
--
PHP CVS Mailing
Hello Sascha,
Wednesday, September 8, 2004, 9:34:51 PM, you wrote:
I can appreciate that there is a limited potential need for PHP to support
chunked encoding right-now, however this is one step in a larger process
I suggest you complete the larger process of cloning curl and
Yep I concur. No need to bloat the code base for no good reason.
Whoever needs the flexibility you are talking of can use CURL.
Andi
At 12:29 PM 9/8/2004 -0700, Sterling Hughes wrote:
Sacha-
I can appreciate that there is a limited potential need for PHP to
support
chunked encoding
Why not integrate libcurl more intimately? I can see Sara's point in
wanting to be able to pipeline http streams, but re-inventing the wheel
doesn't seem like a good idea either. Get the streams code to use the
appropriate features in libcurl, if present. We should be able to solve
the problem
On Wed, 8 Sep 2004, Andi Gutmans wrote:
Yep I concur. No need to bloat the code base for no good reason.
Whoever needs the flexibility you are talking of can use CURL.
Maybe another alternative would be to revive the cURL wrappers
project? That would give us the benefits of being able to
pollita Wed Sep 8 19:37:55 2004 EDT
Modified files:
/php-src/ext/standard http_fopen_wrapper.c
Log:
http://cvs.php.net/diff.php/php-src/ext/standard/http_fopen_wrapper.c?r1=1.91r2=1.92ty=u
Index: php-src/ext/standard/http_fopen_wrapper.c
diff -u
25 matches
Mail list logo
