Re: Fwd: Re: [PHP-DEV] Woah
On Sun, Sep 09, 2001 at 12:46:17AM +0300, Zeev Suraski wrote: Fact - gettext(foo) is much less magical and much more understandable than _(foo). I think the problem here is that internationalization is being considered a 'separate module', rather than a core piece of functionality that PHP should account for. Right now, wrapping _() around EVERY string is only the first step. Then you have to figure out how .po files, bindtextdomain, various environment variables, and all the other stuff that gettext imposes on the system actually work. So where have the PHP ideals disappeared to in simplying this? This whole _() argument is merely a symptom of the underlying problem that internationalizing PHP scripts is really actually quite difficult and intrusive. Fix that, and this particular problem goes away. If you really believe that deprecating _() is a good thing in the context of using gettext, I find it hard to believe that you've actually implemented i8n in PHP for a large project. Personally, I've only used it when Horde switched to it, and I think I'd go mad if I had to wrap every string in the full version of gettext() ! The GNU manual expresses this pretty well: the textual overhead per translatable string is reduced to only three characters: the underline and the two parentheses When we're talking about every single string in your project, that's pretty significant. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
On Sun, Aug 19, 2001 at 07:23:18PM +0200, Hojtsy Gabor wrote: Text diff is not working at Chora, at least with IE 5.00, as it thinks that it needs to display XML content, and just prints out an XML error. Just the Human readable one works... :(( Please elaborate. Is this not working for any files, or only specific files (with an XML extension), and only with IE 5.00? And what do you mean XML Error ? Someone reported a Chora error at [EMAIL PROTECTED] It seems he uses Konqueror, and Chora can't find the default language file to display for him: Chuck fixed this, was just a config problem. The version of Chora now has several language translations available (should autodetect form the browser's Accept-Language headers). Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
On Sun, Aug 19, 2001 at 12:31:22PM -0700, Rasmus Lerdorf wrote: Maybe Chora puts out an XML content type header, or something, that makes IE think this is XML (as it is not). I can't see the source, as IE just denies to show the source in such cases saying The XML source file is unavailable for viwing). Please ask, if more information is needed IE is a completely useless web browser. It does not honour mime types and simply uses the file extension and/or any client-side file type associations. Chora is doing the right thing. On that com.xml URL you posted it is sending a text/plain Content-Type header. The fact that IE choosed to pass text/plain to an internal XML parser is just one more reason you should never use IE for web browsing. You never know what the thing is going to do. I would not suggest changing Chora in any way with this respect. Agh, I see the problem now. One workaround is to disable the 'use_path_info' option in Chora, which will result in IE seeing a '.php' extension instead of the '.xml' extension. The old PATH_INFO urls will still work, but new links will use GET propagation for the cvs-path. Another one is to pad the PATH_INFO for diffs with a '.txt' extension which will fool IE. I don't think I'll bother doing this when the above option is much cleaner. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
On Sun, Aug 19, 2001 at 11:29:18PM +0300, Stanislav Malyshev wrote: It does even worse. It tries to guess file type from the content. I hope somebody will invent some worm that uses this misfeature so that they would finally fix it... Guessing the file-type from the first few magic bytes is probably a good thing (especially in the case where other methods have failed, and the MIME type has fallen back to application/octet-stream or something equally unhelpful). The bug here is that it ignores the explicit Content-Type header instead of its own detection mechanisms, which is clearly bad. Anyone want to file a Microsoft bug report? :-) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
On Mon, Aug 20, 2001 at 04:01:39AM +0300, [EMAIL PROTECTED] wrote: well, but if I send foo.gif and it starts with some friendly VBScript I won't bet you'll think the same. Yes I would ... I'm referring to content-MIME mapping, and it doesnt matter if this happens on the client or server, as long as there's a sensible precedence order (which is the source of this IE/Chora problem - it's not obeying the server response headers). VBScript is irrelevant unless IE does something monumentally stupid like execute scripts while trying to sniff the MIME type. Anyway, this is rapidly getting OT (even by php-dev's lax standards :) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] mcrypt broken?
Testing PHP-4.0.7RC1 on OpenBSD-2.9, w/ libmcrypt-2.4.15 Mcrypt seems a bit broken; even calling nothing but mcrypt_module_open results in Warning: Unknown list entry type in request shutdown (0) in ... Anyone else seeing this problem? Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Cynic wrote: Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all simplicity I can see. I think that's the whole point ... 1) $foo 2) $_GET[foo] One looks like PHP, the other looks like Perl :-) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
Alexander Merz wrote: Please, could you use relative specifications (font-size: small) instead of absolute (font-size: 11px) in the css? It's more user-friendly and i don't have to look for my eyeglasses each time. Unfortunately, this isn't consistent cross-platform. http://www.alistapart.com/stories/fear4/4.html (thx Jim Winstead for the above link) I'm completely open to better solutions, but haven't actually be able to find any. We _could_ start browser sniffing I guess. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
Rasmus Lerdorf wrote: Chuck installed his PHP-based cvs browsing app. It is available at http://chora.php.net. Go have a look. I think it looks really good and we should probably make it the default for http://cvs.php.net. Anybody see any reason not to do that? Cool!! A few things I noticed: Fix the mime_drivers.php to point to tar correctly. http://chora.php.net/co.php/phpweb/Mirrors-htdig.tgz?sa=1r=1.4 and GNU Enscript in there can pretty-print C files as well, if you want. And if you put an entry in for cvsusers in the cvsroots.php config file, it will automatically expand committer's full names and email addresses. Heh, it's great to see it up on php.net :-) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
Rasmus Lerdorf wrote: By the way, do you think it would be possible to put the CVS commit message at the top of the long diff coloured output? Yeah, I've already got a similar change in my local tree that shows the commit message on the checkout. I'll add it in for the diff view as well. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] CVS Account Request
[EMAIL PROTECTED] wrote: Ok. I need to sit down and document how to add a C extension to PEAR. Has anyone worked on enabling multiple SAPI modules in one compile yet? Stig committed some stuff a while back but reverted it. If that's done, and we can generate a CGI version of PHP at the same time as an APXS version, it would make things go a long way towards making the PEAR binaries more useful. cheers, Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] multiple compilations of SAPI
Stig made a brave attempt at allowing the compilation of multiple SAPI modules simulataneously a while back, but I think this never made it through to php-4.0.[5|6]. Is there any chance this could get looked at before 4.0.7? It would make it so easy to install the CGI binary for PEAR as well as the APXS module. Cheers, Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.6RC4 out.
Andi Gutmans wrote: Please test it http://www.php.net/~andi/php-4.0.6RC4.tar.gz No problems so far on OpenBSD-2.9-stable/i386 4.0.5 gave me annoying problems of an httpd process going into an endless loop taking up 100% cpu. This doesn't appear to happen any more with 4.0.6, although it's a bit early to tell for sure. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] extension/module versioning
[EMAIL PROTECTED] wrote:
$version_id = xml_version();
or
$version_id = ibase_version();
Probably better to do something like this:
$version = get_extension_version('xml');
to avoid cluttering the namespace with more functions.
Although, why not just use phpversion() ? Extensions aren't really
versioned separately are they?
Anil
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: Bug #10581 Updated: signal 6 when starting server
Without more information it's pretty impossible to solve (I don't have access to an iPlanet installation at the moment). Can anyone else look at the problem with iPlanet 4.x? Otherwise you'll have to try to dive in yourself, Mark. Did it work with an older version of PHP? Try looking at the SAPI code differences and see if you can spot what's changed to break it. Anil - Original Message - From: Faine, Mark [EMAIL PROTECTED] To: 'Bug Database' [EMAIL PROTECTED] Sent: Tuesday, May 01, 2001 8:29 PM Subject: [PHP-DEV] RE: Bug #10581 Updated: signal 6 when starting server It's possible but it wouldn't be easy, for one I don't have gdb installed, AFAIK it doesn't come with Solaris so I'd have to install it. Also, I compiled with --disable-debug. Then there the fact there is no core file and I don't even know if I could get any kind of information from iPlanet even if I recompiled and installed gdb. -Mark -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 2:20 PM To: [EMAIL PROTECTED] Subject: Bug #10581 Updated: signal 6 when starting server ID: 10581 Updated by: avsm Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: iPlanet related PHP Version: 4.0.5 Assigned To: Comments: Hmm, need backtraces from gdb to show where things are going wrong ... is that possible? (not sure if you can get get debugging symbols from iPlanet) Previous Comments: -- - [2001-05-01 15:16:28] [EMAIL PROTECTED] User Feedback: Yes, that was the first thing I tried, the server will start with these changes but will timeout on every page, even non-php pages. No page will load. It's Netscape iPlanet Server 4.0 SP5 -- - [2001-05-01 15:00:30] [EMAIL PROTECTED] Have you tried these entries in obj.conf ? Init fn=load-modules shlib=/path/to/server4/bin/libphp4.so funcs=php4_init,php4_close,php4_execute,php4_auth_trans Init fn=php4_init LateInit=yes These fix a library loading problem; if it doesn't fix yours, then we have to keep on searching. Incidentally, what version of iPlanet are you running? -- - [2001-05-01 14:47:28] [EMAIL PROTECTED] My bug is exactly the same as Bug id #10012, except for my OS/PHP/Web server version differences. I am getting exactly the same error. I have set everything up correctly as stated in: http://www.php.net/manual/en/install.netscape-enterprise.php Error Message follows: Status: [https-bc_devel]: start failed. (2: unknown early startup error) [https-bc_devel]: server terminated (signal 6): watchdog is restarting it [https-bc_devel]: failure: server initialization failed Error An error occurred during startup. The server https-bc_devel was not started. Return to process control Also, I don't even get that much when I try to start from the console. I get no error message at all, logs don't even say what the problem was? Strange. This is still not working, I'd go back to 4.0.4 pl1 but it's got it's own problems. Anybody? -- - [2001-05-01 11:43:56] [EMAIL PROTECTED] My bug is exactly the same as Bug id #10012, except for my OS/PHP/Web server version differences. I am getting exactly the same error. I have set everything up correctly as stated in: http://www.php.net/manual/en/install.netscape-enterprise.php Error Message follows: Status: [https-bc_devel]: start failed. (2: unknown early startup error) [https-bc_devel]: server terminated (signal 6): watchdog is restarting it [https-bc_devel]: failure: server initialization failed Error An error occurred during startup. The server https-bc_devel was not started. Return to process control Also, I don't even get that much when I try to start from the console. I get no error message at all, logs don't even say what the problem was? Strange. -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10581edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5: Merge Request
Zeev Suraski wrote: Deciding 4.0.6 won't include any significant new features, and that we'll start its release process after a bugs-database -cleaning period sounds like a good idea to me. So why restrict it to just the next release? It might make a lot of sense to have an RC candidate much more often, but with a longer QA period to fix all these bugs. Kind of like FreeBSD; have a -current, and a -stable branch. It's sort of been going that way with the 4.0.5 release (there's been a lot of uptake on merging bugfixes, but not adding new features, except for FastCGI). Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
ALL extensions are in PEAR, and a download tool allows easy selection of extensions, perhaps with a 'most common options' button to include the favourite extensions. Also, if you put most of the extensions into PEAR initially, it would be easy to monitor the download statistics to find the most popular ones, and integrate them into core PHP from that point. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
Derick Rethans wrote: I would go for optionally on, I really dont want to build both the apache module (p.e.) AND the CGi at the same time. For QA testing this is fine, but not for production servers. Well, it really beats the alternative, which is to compile everything twice ... what's wrong with having a PHP cgi sitting around on a production server by the way? It's very handy when trying to debug stuff, and doesn't intrude on any normal processes either. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch
Sascha Schumann wrote: No. The alternative is to pass --enable-cgi on the command-line. ? This doesn't work (nor is it listed in the --help options to configure) I mean to compile a CGI and APXS DSO in a single compile, not two. My understanding is that only one SAPI module can be selected at a time right now. I would love to stand corrected; it's one of my prime problems with the OpenBSD port right now. If the administrator installs it unknowingly, the CGI might get installed with inproper permissions which lead to potential security problems. It's not SUID, so what's the problem? A clear note in the NEWS file that this behaviour has changed should be enough for administrators of chrooted or otherwise secured systems (if they blindly update without examining changes, then they aren't running a very tight ship anyway). I respect the wishes of the QA team, but please don't force your will upon all PHP users in exchange for a bit of convenience. If PHP doesn't start installing a CGI by default, then PEAR is going to have a few problems - its installer depends on that CGI. And how many end users actually run regression tests right now? If the CGI is there in /usr/local/bin, then a lot more users can do this, instead of just the small QA team. CPAN feedback from 'make test' must be quite useful to them ... Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
It's the arg_separator changes isn't it? Both '' and ';' are valid delimiters in a URL, so the new 4.0.5 behaviour is actually the valid one, I believe. Refer to the XHTML specification, or check out the bugs db for this. Anil - Original Message - From: "Andi Gutmans" [EMAIL PROTECTED] To: "Andrew Sitnikov" [EMAIL PROTECTED]; [EMAIL PROTECTED]; "php-dev mailinglist" [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 6:21 PM Subject: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6 Anyone have an idea why this happens? Andi At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote: Hello php-qa, test.php ? echo $test; ? http://host/test.php?test=1;2;3 4.0.4pl1 Result: 1;2;3 4.0.5RC6 Result: 1 Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Andi Gutmans wrote: Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Zeev's output buffering fix hasn't been committed yet; it's a one-line change, and it makes the transparent output compression stuff work. Does anyone have any objection to an MFH on the small Vary header patch also? It improves PHP's RFC2616 compliance, but it also unbreaks almost every web-cache, which rely on having it present for content-negotiated pages. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
Andi Gutmans wrote: I suggest you merge this into 4.0.5 because it seems to me that otherwise output buffering will be quite a mess without it. It would be a shame to release 4.0.5 without it. Ok, done. Your fix looks OK but I'd like to hear the opinion of someone else who is more familiar with RFC2616. Hope I didn't jump the gun with the merge (read this mail right after the commit). Here is the relevant excerpt from the RFC: 13.6 Caching Negotiated Responses Use of server-driven content negotiation (section 12.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers. A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers. When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request. Note that the current PEAR implementation of HTTP::Compress sends exactly this Vary header also, and works great. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Output Buffering problem w/ PHP-4.0.5RC2
Making HEAD requests to a page which has had output buffering activated just results in the connection being closed with no response. This makes it pretty unusable. Can anyone else reproduce this problem? Two scripts: nobuffer.php: ? print "hello world!"; ? buffer.php: ? ob_start(); print "hello buffered world!"; ob_end_flush(); ? nobuffer.php responds to the GET/HEAD requests fine. buffer.php responds correctly to the GET, but not the HEAD. Transcript is below: [avsm@brick /]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /~avsm/nobuffer.php HTTP/1.1 Host: localhost HTTP/1.1 200 OK Date: Thu, 29 Mar 2001 22:48:24 GMT Server: Apache/1.3.12 (Unix) PHP/4.0.5RC2 mod_ssl/2.6.6 OpenSSL/0.9.5a X-Powered-By: PHP/4.0.5RC2 Transfer-Encoding: chunked Content-Type: text/html c hello world! 0 [avsm@brick /]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD /~avsm/nobuffer.php HTTP/1.1 Host: localhost HTTP/1.1 200 OK Date: Thu, 29 Mar 2001 22:49:00 GMT Server: Apache/1.3.12 (Unix) PHP/4.0.5RC2 mod_ssl/2.6.6 OpenSSL/0.9.5a X-Powered-By: PHP/4.0.5RC2 Content-Type: text/html [avsm@brick /]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /~avsm/buffer.php HTTP/1.1 Host: localhost HTTP/1.1 200 OK Date: Thu, 29 Mar 2001 22:49:34 GMT Server: Apache/1.3.12 (Unix) PHP/4.0.5RC2 mod_ssl/2.6.6 OpenSSL/0.9.5a X-Powered-By: PHP/4.0.5RC2 Transfer-Encoding: chunked Content-Type: text/html 15 hello buffered world! 0 [avsm@brick /]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD /~avsm/buffer.php HTTP/1.1 Host: localhost Connection closed by foreign host. I'll upgrade to RC4 in a bit and check if that makes a difference (not seen the ChangeLogs between them yet) (Platform is OpenBSD-2.8-stable). There is nothing in the Apache error log. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Output Buffering problem w/ PHP-4.0.5RC2
I'll upgrade to RC4 in a bit and check if that makes a difference (not seen the ChangeLogs between them yet) (Platform is OpenBSD-2.8-stable). There is nothing in the Apache error log. The problem is still there in RC4 also. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] free() errors in PHP-4.0.5RC1
One of my OpenBSD servers hosed itself overnight, after the upgrade to PHP-4.0.5RC1. The problem was that the webserver suddenly segfaulted all of its children (saw this in the error log), and then dumped around 900MB worth of errors into the error log. This hurt my /var partition :-) The errors are: httpd in free(): warning: chunk is already free. httpd in free(): warning: chunk is already free. httpd in free(): warning: chunk is already free. httpd in free(): warning: chunk is already free. httpd in free(): warning: page is already free. httpd in free(): warning: chunk is already free. httpd in free(): warning: chunk is already free. httpd in free(): warning: chunk is already free. ... until /var fills up ... Now, this is a BSD warning, and I can turn it off by fiddling with /etc/malloc.conf, but the fact that it's showing up is a bit iffy. Anyone got any insight? Nothing like this happened using PHP-4.0.4pl1 or previous. More details will be forthcoming if I can reproduce the problem (it doesn't help that the Apache error logs seem to lack a timestamp). This is the server that runs demo.horde.org, so it primarily uses the IMAP module for remote, unstable connections. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
Zeev Suraski wrote: Stability is irrelevant with new modules - they did not exist before, so they can't be less stable, and figuring whether their addition breaks PHP is trivial, and would be discovered in a second if they manage to do that somehow. New modules are no different from any of the unstable modules that exist in PHP, and there are plenty of them. The point is, why did this issue come up in the first place? The time between releases is large, and the time in RC-branch is small. If it's so important that this module makes it in (which I can agree with), then I'm surprised it wasn't brought up when you first announced that PHP-4.0.5 would be out soon (which was a good bit of notice before RC). If it was a time issue, it wouldn't have hurt to delay the RC by a week or so until all the features were in, after all this time waiting for it :-) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bi-directional popen()
This has come up a few times, but is there any chance of having a bi-directional popen() that doesn't depend on the underlying system call supporting it? It would hugely speed up and clean up a lot of code that interacts with the system, but right now it only works under FreeBSD/BSDi that I found, and isn't really widely deployed. Perl's had this capability for a while, so it must be possible somehow (although I haven't delved into its implementation) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9136: simple script with infinite function calls causes seg fault
Sean R. Bright wrote: Because I don't consider it a problem that needs solving. I am probably overlooking some notoriously famous algorithm, but I can't think of a valid reason for such functionality to exist unless someone is purposely trying to bring a system to its knees. How about ... no PHP script should ever cause the webserver to segfault? Segfaults are bad. Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9029: preg_split inconsistency
Quoting Andrei Zmievski [EMAIL PROTECTED]: I could add this functionality but I am not sure if it would break people's scripts because they used parentheses without expecting to receive captured delimiters. What does everyone think? Should it be that way by default or should we have another PREG_SPLIT flag, e.g. PREG_SPLIT_DELIM_CAPTURE? And if we have a flag can it be combined with PREG_SPLIT_NO_EMPTY? Well, given that the aim of the function is to be as perl-compatible, it would be nice to make this default behaviour. The breakage of any scripts would be pretty easy to spot, if they did use brackets wrongly, so an entry in NEWS ought to enough ? -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] http://cvs.php.net/
Quoting Sebastian Bergmann [EMAIL PROTECTED]: http://demo.horde.org/devel/horde/chora/cvs.php?rt=php and wondered how great it would be to put this on http://cvs.php.net to replace the CGI tool that currently does the job. Just curious :) It's pretty stable, but not quite ready for production yet. I'm working on the MIME stuff at the moment, and the UI is still a bit shaky. Feedback, as always, is more than appreciated (especially about new ideas for the interface). Patches are even more appreciated :-) -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Legal solution: RE: [PHP-DEV] Non-GPL readline
Quoting Zeev Suraski [EMAIL PROTECTED]: However, if your code is compatible with a GNU library, which is, in turn, compatible with some other library (commercial, BSD) that is legal to link with PHP, then things change. Obviously, this all story about encouraging the users to break the license is no longer relevant, and the whole bogus-to-begin-with story of not allowing to release code that is 'compatible with a certain library' becomes rediculous. This whole affair is turning into an alarming waste of time as well; if this were something like the mysql module, then it would be a lot more worrying, but how many people use the _readline_ module with PHP? I'm sure all two of them would find an alternative if it were to disappear :-) -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Non-GPL readline
Quoting Stanislav Malyshev [EMAIL PROTECTED]: 2. Can we just rip the code out the NetBSD CVS (like I did) and insert it into PHP? License seems to allow this, provided all the thing with advertising clauses, but there might be things more complicated than I thought of. Keeping this in sync will might be a pain. We're currently syncing the NetBSD stuff (mainly by christos), over to OpenBSD as well (as well as submitting back our security patches to it). Would it be better if this were spun off as a separate library release (perhaps synced to/from NetBSD versions, but with distinct versions), as desire for the separate lib grows? 3. If 1+2 is yes, do we want to still retain the GNU readline compatibility, or we want full replacement (with probably some functionality loss). Yeah, there is a loss of functionality. Some readline programs that use v4.x simply dont compile due to the functions not being there (yafc), but christos says that he is gunning for full readline compat, which should be excellent. -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.4 patchlevel 1 released
Quoting Phil Driscoll [EMAIL PROTECTED]: my ISP reckons that the DNS machines for php.net are not giving authoritative responses. Just to confirm this problem (I have it too) 1 www.php.net 212.100.224.80 ALERT: lame server; refers to net 1 www.php.net 64.39.29.212 ALERT: lame server; refers to net 1 www.php.net 216.220.40.244 16822 A 208.247.106.187 1 www.php.net 216.220.40.243 21600 A 208.247.106.187 The first two NS servers for php.net remote[1|2].easydns.com seem to pointing to the .net root servers, and I can't resolve php.net. I'm using djbdns, the above is an excerpt from running $ dnstrace a www.php.net 198.41.0.4 | dnstracesort -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] cgi+dso
I was wondering if there's currently any way to compile up both the CGI version, and the Apache DSO in a single compile? Looking at the autoconf stuff implies that there isn't, since there's a single PHP_SAPI variable that defaults to cgi. Is there any interest in this changing? With the rise of PEAR, it's more and more important to provide a binary, and I'd like to install it by default on the OpenBSD port. However, it seems a bit wasteful to require two compilations, when the vast majority of what is compiling stays the same. -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
