RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi, OK, this looks fine. Maybe we should involve Oracle people. Unfortunately, I have no direct contact regarding iPlanet. I have good contacts to the Oracle Quality Assurance team in Ireland, but that is regarding Java. But those people are not responsible to this issue. At the time I was investigating on the RFC, there already was a negative answer from the iPlanet team. So we already knew at that time they won't support it, it's stated in the RFC. Yes. But they never ever supported the plugin actively, so this was no real news at the time of the RFC. The SAPI was originally written by Jayakumar Muthukumarasamy, I took over in 2003. At that time there was no FastCGI support in the webserver, so the NSAPI plugin was the only working solution - and a great one (with just the well-known TLS problems, which was PHP's fault, not Sun/Oracle's). I improved it to be as most compliant to the Apache SAPI - it (still) works fine with most Content Management systems and MediaWiki (if you manage to make Rewrite rules of Apache working, that those CMS mostly need; this was fixed in iPlanet 7, where you can have rewrite rules - just with other syntax). In my personal opinion: If you have contact to iPlanet people at Oracle, maybe you should contact them again (or send me the contact details). If they would provide a working (developer) download location for the latest 7.0.21 version (released a month ago with TLS 1.2 support), we could start supporting it. But without any download location, it is impossible to support it. You should also remind them: Although they recommend to use FastCGI, it is impossible to support this webserver from our side without a developer download to test. So we can verify that FastCGI works. I would like to have support for handling error pages with FastCGI (so you can present 404 not found pages using PHP or directory listings). All this was possible with the NSAPI plugin, but to test this out with iPlanet and FastCGI we would need a download location. But if they show no interest, let NSAPI die :-( Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi Anatol, you may know that I am the maintainer of the NSAPI SAPI module. I spent a lot of time in improving it. The next update would have been to change it to the PHP 7 threading model, but based on recent experience with Oracle, I will stop maintaining the plugin. We should not remove it from PHP 5, but it should no longer be available for PHP7. The reason for this decision is: - Oracle seems to no longer have any interest in maintaining any public accessible developer downloads, you can now only order the product and download installation files (and therefore header files) through their paywall. All references to the OTN (Oracle Technology Network, means developer licenses) downloads were removed completely from their web pages. This happened after I asked a question on their support forums (which was moderated away), where the OTN downloads for the latest version including TLS 1.2 support are located now. This lead to the fact that they disabled the download page completely (and my post was moderated away, which is a really bad behavior, sorry I have to say this!). Somebody there should have known that I am the person who worked closely together with the people working on the iPlanet/Sun Webserver at Sun Microsystems times. This is annoying. - I am also phasing out use of this webserver privately, because the new conditions are unacceptable. In my opinion, this webserver was a great piece of nice and fast software, including - next to PHP - Java web application support inside the webserver, so there was no need to have stuff like reverse proxies needed (the usual Tomcat behind a reverse proxy Apache), because the Java code was running inside the web server (and this made it very fast). Of course, PHP support (when used through the NSAPI plugin) was great, too, because there was no overhead (although some PHP extensions were not compatible, because this webserver runs in a multithreaded way). People that still want to stay on iPlanet webserver can fallback to using FastCGI, which has some pitfalls, but generally works. The NSAPI plugin allowed to do much more like binding PHP script to directory (allowing to make custom PHP-based directory listings), or error pages. This is impossible using FastCGI as far as I know. I am sorry, I have to stop supporting it, because Oracle killed the last piece of good software :-( If there needs to be some decision about removing this plugin through an RFC, I can trigger one, but to me the above changes in Licensing make it impossible to longer support this piece of software. Uwe Thanks for the information. It's of course sad. I personally was hoping to be able to work and debug with one more real multi-threaded SAPI besides Apache. But so is the life. We've already had the NSAPI SAPI in the RFC suggesting removals https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#sapinsapi . As preparations I was building and testing every item in that RFC I could get my hands on. But for sapi/nsapi I couldn't get the environment already at that time, so I wasn't able to test it. It's senseless to guess how this item would have been voted. But with the addition of the knowing you shared today it looks pretty much that we should not carry it with PHP7. If one even cannot get the dependency library, except one has to buy it, it's a blocker. Well, except one wants to buy it :) Now, as that was the RFC I was working on, here are the steps I would suggest. Maybe there were a chance to ask for an exception for PHP project, you personally or whatever (if you're still interested)? As I described in my post before, I am a little bit annoyed becaue of Oracle's behaviour. I was just asking for a more up-to-date developer download on their forum around iPlanet web server. The reaction to that was: - initially the post was automoderated (review) - that's just fine - after a few days (when I came back to the forum), the web interface notified me that my post was blocked by a moderator. - in parallel to that, the download to the older version (v7.0.15) was removed! To me this looks like (this is just some: - Oracle wasn't aware that there was still a download to the older version (it was also hidden on their web page, you had to know what to enter into Google). - My forum request triggered a review of their web page - they removed the downloads - By post was blocked to hide that fact, that it was available in earlier times (and they maybe did not know). - All other questions from other people about where to download the newer version were answered with an Oracle patch ID #foobar and a link to the paywall (those questions were without reference to free OTN downloads, so they were not blocked by moderator). Because of this really bad behavior, I am a bit annoyed. Maybe they can fix this, but I would like to have a reaction from their side. I would then try to
[PHP-DEV] RIP: NSAPI SAPI Plugin (unfortunately - thanks Oracle)
Hi, you may know that I am the maintainer of the NSAPI SAPI module. I spent a lot of time in improving it. The next update would have been to change it to the PHP 7 threading model, but based on recent experience with Oracle, I will stop maintaining the plugin. We should not remove it from PHP 5, but it should no longer be available for PHP7. The reason for this decision is: - Oracle seems to no longer have any interest in maintaining any public accessible developer downloads, you can now only order the product and download installation files (and therefore header files) through their paywall. All references to the OTN (Oracle Technology Network, means developer licenses) downloads were removed completely from their web pages. This happened after I asked a question on their support forums (which was moderated away), where the OTN downloads for the latest version including TLS 1.2 support are located now. This lead to the fact that they disabled the download page completely (and my post was moderated away, which is a really bad behavior, sorry I have to say this!). Somebody there should have known that I am the person who worked closely together with the people working on the iPlanet/Sun Webserver at Sun Microsystems times. This is annoying. - I am also phasing out use of this webserver privately, because the new conditions are unacceptable. In my opinion, this webserver was a great piece of nice and fast software, including - next to PHP - Java web application support inside the webserver, so there was no need to have stuff like reverse proxies needed (the usual Tomcat behind a reverse proxy Apache), because the Java code was running inside the web server (and this made it very fast). Of course, PHP support (when used through the NSAPI plugin) was great, too, because there was no overhead (although some PHP extensions were not compatible, because this webserver runs in a multithreaded way). People that still want to stay on iPlanet webserver can fallback to using FastCGI, which has some pitfalls, but generally works. The NSAPI plugin allowed to do much more like binding PHP script to directory (allowing to make custom PHP-based directory listings), or error pages. This is impossible using FastCGI as far as I know. I am sorry, I have to stop supporting it, because Oracle killed the last piece of good software :-( If there needs to be some decision about removing this plugin through an RFC, I can trigger one, but to me the above changes in Licensing make it impossible to longer support this piece of software. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, I gave my votes (where I can talk about). I am still maintaining the NSAPI SAPI. It does not meant that its dead if no commits were made. NSAPI upstream API just did not change since years, so why change a running system? The current version of this SAPI (5.6) runs perfectly with MediaWiki and several CMS systems on latest Oracle iPlanet server in production. The information about NSAPI you gave (The developers of iPlanet @Oracle wrote back, that they're not intended to support this SAPI starting from PHP7 onwards.) is not applicable, because people from Sun/Oracle never provided any support or this extension - you should have asked the maintainer (me). Oracle just recommends fcgi, because it might be more stable if you use non-threadsafe extensions, but otherwise the server is perfectly stable and very fast. Oracle employees only helped with one patch, otherwise it was mostly (re-)written by me. In addition, the server works perfectly fine on Ubuntu 14.04, so it will also run on Debian. It can be downloaded with Oracle OTN license, header files are included. You can compile PHP 5.6 with it as documented: http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserver-525365.html If there are changes needed in the SAPI for PHP 7, I can take care, I just have not looked into it. It should not be a problem for me to update it, unless significant changes in the PHP API occurred since my last commit (yes, I am a bit inactive, but still following the development). Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Anatol Belski [mailto:anatol@belski.net] Sent: Monday, February 02, 2015 8:45 PM To: Andrey Andreev Cc: Nikita Popov; Anatol Belski; PHP internals Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions On Mon, February 2, 2015 20:30, Andrey Andreev wrote: Oh, forgot one thing ... Mcrypt might be dead, but removing it would be a huge BC break. There was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest that instead of removal. that sounds plausible, but the same one could say about mapping to be removed regex to pcre. If anything of that is going to be happening, so I would welcome another RFC and implementation. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Removal of dead SAPIs
Hi, NSAPI is not dead, server is still downloadable: http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserver-525365.html There were just no code changes by me because there were no new features - a SAPI is just plain thumb, so the number of commits is low. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: marius adrian popa [mailto:map...@gmail.com] Sent: Thursday, September 18, 2014 11:09 AM To: PHP Developers Mailing List Subject: [PHP-DEV] RFC: Removal of dead SAPIs Maybe is time to vote and implement it in php 7 with a pull request for each sapi https://wiki.php.net/rfc/removal_of_dead_sapis tux is dead for almost 10 years thttpd does have a fork that seems maintained from git log http://opensource.dyc.edu/sthttpd http://opensource.dyc.edu/gitweb/?p=sthttpd.git;a=summary -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
Hi, I would update NSAPI as I always did, there were just no new bugs and code is very stable (to the extend of stableness of multithreaded SAPIs). It is still also in use on some of my servers, so I would still help support it. At the moment I did not follow recent commits to SAPI-related code, so I have to closer look into it. Are there any RFCs related to changes coming in 5.6 for OPcache? Unfortunately I did not do any commit since we moved away from SVN... Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Terry Ellison [mailto:ellison.te...@gmail.com] Sent: Monday, August 19, 2013 6:05 PM To: internals@lists.php.net Subject: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support? By way of a background. I've been doing a review of the exting code base looking at how to establishing a roadmap extend OPcache functionality across all supported OSes and SAPIs. And this raises a supplementary Q: which OSs and SAPIs should we be supporting for PHP 5.6 anyway? I would be interested in the views of the dev team on this. It would be good to agree a list of which OSs are to be supported at PHP 5.6, which SAPIs are supported, and a matrix of which SAPIs are supported on non-threaded and build TSRM variants. Examples of what I am talking about are SAPIs with no clear evidence of active support (I've listed the last non-bulk change in brackets to give a measure of the level of support): aolserver (2008), caudium (2005), continuity (2004), nsapi (2011), phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002), tux (2007), webjames (2006) I realise that some of these may still be actively used with a user community out there wanting to track current versions, and this is just a case of if ain't broke... However, I do wonder when some of these were actively maintained and routinely tested against the current versions at release -- and if not then perhaps PHP 5.6 is the correct point to retire them from the source tarball and configure options? Likewise in the Zend, TSRM, ext/opcache ... sources, there is conditional code dependent on BeOS, __sgi, __osf__, __IRIX__, NSAPI, PI3WEB, GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs that are no longer actively supported. Again I ask the Q how and when are these tested and if not then shouldn't we retire this support? Part of my reasons for asking this is work in preparation for OPcache issue #118 -- Transparent SHM reuse. Doing this with robustly with good performance characteristics -- for *all* currently referenced OSs -- is a pain. Reviewing a range of other best-of breed packages which use shared SMA- based resources, it seems to me that the memcached approach is the cleanest: it uses the POSIX APIs and supports any OSes which support these APIs. If we limited TSRM and OPcache support at PHP 5.6 to two code variants, POSIX + WIN32, surely this would still cover all the major supported OSes? //Terry Ellison (*) GNU threads is still supported but it prevents utilisation of SMP systems and there is a minimal performance differences from POSIX threads on a single processor system. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bug 18556 - tolower locales
Hi Nikita, That was my first problem with the code, too! I would make the Zend engine use the ROOT Locale for PHP's language parsing (in Java it's called Locale.ROOT, in C its the Locale named ), so its invariant to local settings but works correct for all of Unicode. In theory, this case insensitive matching should *not* be done by lowercasing, in Unicode the correct way to do it is by case folding, which is something different (but using the ROOT locale has almost the same effect). In general methods like Java's String.equalsIgnoreCase(String) do this internally. I don't think ASCII-only lowercasing is in-compatible to the allowed PHP identifier characters used by class names and what else. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Nikita Popov [mailto:nikita@gmail.com] Sent: Wednesday, July 11, 2012 11:41 AM To: Stas Malyshev Cc: PHP Internals; Johannes Schlüter Subject: Re: [PHP-DEV] bug 18556 - tolower locales On Wed, Jul 11, 2012 at 7:40 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I've prepared a fix for bug #18556 - see https://github.com/php/php-src/pull/126 A slight complication there is that for internal operations we probably want locale-independent lowercasing, while for regular string operations we probably want to stay with locale-depenedent one. That's how I implemented it, even though it adds a bit of complexity, but I think it's the best way to solve it. Any comments/objections/improvements? With this patch, will it still be possible to use foreign class names correctly? Like writing them in Russian and expecting the case-insensitivity to work correct? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bug 18556 - tolower locales
Sorry, typo: I don't think ASCII-only lowercasing is in-compatible to the allowed PHP identifier characters used by class names and what else. I don't think ASCII-only lowercasing is compatible to the allowed PHP identifier characters used by class names and what else. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Nikita Popov [mailto:nikita@gmail.com] Sent: Wednesday, July 11, 2012 11:41 AM To: Stas Malyshev Cc: PHP Internals; Johannes Schlüter Subject: Re: [PHP-DEV] bug 18556 - tolower locales On Wed, Jul 11, 2012 at 7:40 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I've prepared a fix for bug #18556 - see https://github.com/php/php-src/pull/126 A slight complication there is that for internal operations we probably want locale-independent lowercasing, while for regular string operations we probably want to stay with locale-depenedent one. That's how I implemented it, even though it adds a bit of complexity, but I think it's the best way to solve it. Any comments/objections/improvements? With this patch, will it still be possible to use foreign class names correctly? Like writing them in Russian and expecting the case-insensitivity to work correct? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] readfile() memory usage
Hi Larry, 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. I implemented this earlier this very year to avoid memory issues (a quick look at project history shows me working on it in January). The difference between using readfile, and some convoluted method from the documentation comments was clear and immediate: corrupted download with out of memory error in the logs, to things working just fine. Let me re-create with a simple test script and share my server details before we call snopes :) Are you sure that you are *not* using ob_start()/ob_flush()/... (output buffering)? If this is the case, readfile writes to the output, but buffers everything in memory, as the PHP output buffering is active? Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] readfile() memory usage
Hi, Readfile() is internally implemented in the same way like fpassthru() (actually the same backend function is called, readfile only opening a stream before delegating to passthru). Both methods delegate from PHP user-space to an internal streams API methods php_stream_passthru(). This one has 2 implementations: - If the underlying stream allows MMAP, it will use memory mapping (mapping file to *virtual* memory) and copy the mapped buffer to output. Please note memory mapping does *not* load the file into memory, it only *maps* the file contents to virtual memory like a swap file (http://en.wikipedia.org/wiki/Mmap). - If this is not the case, it copies the whole file in blocks of 8192 bytes using a conventional loop. I verified, this code is at least in PHP 5.2 and 5.3, maybe earlier, too. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, April 30, 2012 7:22 AM To: internals@lists.php.net Subject: [PHP-DEV] readfile() memory usage So, I've been reading articles for a decade now that say that readfile() is great and wonderful except for memory usage. Specifically, that it reads a file into memory entirely, and then prints it to stdout from there. So if you're outputing a big file you will hit your memory limit and kill the server. Thus, one should always loop over fread() instead. The most recent article I found saying that was from 2007, with a StackExchange thread saying the same from 2011. I've even found mention of it in old PHP Bugs. However, I cannot replicate that in my own testing. Earlier today I was running some benchmarks of different file streaming techniques in PHP (5.3.6 specifically) and found that fread() looping, fpassthru(), readfile(), and stream_copy_to_stream() perform almost identically on memory, and all are identical on CPU except for fread() which is slower, which makes sense since you're looping in PHP space. What's more, I cranked my memory limit down to 10 MB and then tried streaming a 20 MB file. No change. The PHP peak memory never left around a half-meg or so, most of which I presume is just the Apache/PHP overhead. But it's not actually possible for readfile() to be buffering the whole file into memory before printing and not die if the file is bigger than the memory limit. I verified that the data I'm getting downloaded from the script is correct, and exactly matches the file that it should be streaming. My first thought was that this is yet another case of PHP improving and fixing a long-standing bug, but somehow the rest of the world not knowing about it so conventional wisdom persists long after it's still wise. However, I found no mention of readfile() in the PHP 5 change log[1] at all aside from one note from back in 5.0.0 Beta 1 about improving performance under Windows. (I'm on Linux.) So, what's going on here? Has readfile() been memory-safe for that long without anyone noticing? Is my test completely flawed (although I don't see how since I can verify that the code works as expected)? Something else? Please un-confuse me! (Note: Sending this to internals since this is an engine question, and I am more likely to reach whoever it was that un-sucked readfile() sometime in the silent past that way. g) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] readfile() memory usage
Hi, mmap may use normal memory too, depending on the options (not sure which are used exactly with readfile or stream's mmap). Mmapping of course uses memory, but the memory used here is not from PHP's memory manager, it's memory that's already used for the O/S cache. The memory mapping used here does not enforce loading the file contents into O/S cache; it just gets a virtual address into the O/S cache. If the actual file contents are not yet in O/S cache, the O/S will hit a page fault and load the pages into memory. Apache Server uses the same mechanism to serve files. Maybe the user confusion about memory usage comes from that fact (they see lots of *virtual* memory used by PHP when viewed in top). I know this user confusion from my work in the Apache Lucene/Solr project, where one option (used on 64 bit operating systems) is to memory-map the whole Lucene full-text index. Users then see hundreds of Gigabytes of virtual memory usage in TOP / Windows Task Manager and are afraid of running their machine out of memory. This is always hard to explain to people that are not used to the term virtual memory. About php memory usage, one has to use an external tools to actually see this memory usage as it is not managed by the zend memory manager. Of course... Thanks, Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] readfile() memory usage
Hi Larry, From my understanding this is correct, except the part about the code history: I am not sure what PHP did in the past (before the new streams API), so before saying that it was always this way, you should review ext/std/file.c and main/streams.c in the GIT/SVN/CVS history! But the other notes seem to be the reason for the persistent urban legends :-) Uwe P.S.: By the way, I will have a MMap blog post, too; focusing on the same urban legends about to the use of Lucene's MMapDirectory in Apache Lucene and Apache Solr. I am just a little bit overcrowded with work. - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, April 30, 2012 7:16 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] readfile() memory usage Thanks all. So it sounds like the answer is: 1) readfile() has always been memory-safe as far as PHP is concerned. 2) Because it uses mmap(), GFL trying to understand its memory usage from top. 3) Operating systems have gotten better at such things in the past decade. 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. Is that an accurate summary? If so, I will blog my benchmark results and this conversation. --Larry Garfield On 4/30/12 5:33 AM, Sherif Ramadan wrote: Mmapping of course uses memory, but the memory used here is not from PHP's memory manager, it's memory that's already used for the O/S cache. The memory mapping used here does not enforce loading the file contents into O/S cache; it just gets a virtual address into the O/S cache. If the actual file contents are not yet in O/S cache, the O/S will hit a page fault and load the pages into memory. Apache Server uses the same mechanism to serve files. Maybe the user confusion about memory usage comes from that fact (they see lots of *virtual* memory used by PHP when viewed in top). I know this user confusion from my work in the Apache Lucene/Solr project, where one option (used on 64 bit operating systems) is to memory-map the whole Lucene full-text index. Users then see hundreds of Gigabytes of virtual memory usage in TOP / Windows Task Manager and are afraid of running their machine out of memory. This is always hard to explain to people that are not used to the term virtual memory. That's a very good point and a detailed look at the stack can show some of the underlying mechanics coming from readfile and how its pretty much is just implemented like fpassthru delegating a stream, as you said. http://i.imgur.com/PWiTv.png About php memory usage, one has to use an external tools to actually see this memory usage as it is not managed by the zend memory manager. Of course... Also, running valgrind and taking a closer look at what memory blocks PHP is allocating here it can be better determined what's leaking and what isn't, of course... http://pastebin.com/LSQcUsBL I can certainly attest to users being deceived by memory readings in top in the past. It can be very deceiving if you think look at what free memory top or `free` shows you especially after some huge allocation. There's a clear difference here though between the Zend memory manager allocating these blocks in PHP and what's going on with readfile. The memory the system knows is available to it isn't being tied up in this case. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Are all HTTP headers registered in SERVER?
Hi, It seems to be the case but this is not documented anywhere on php.net. Instead http://php.net/manual/en/function.apache-request-headers.php say You can also get at the value of the common CGI variables by reading them from the environment. For the environment is no longer true, most multi-threaded webservers don't have separate environments for every thread (because they can't). You should only use $_SERVER! The global $_ENV is only safe to use in php-cli, where you have an defined environment, but not inside webservers. Only apache currently sets the $_ENV equally to the $_SERVER, but only when used in prefork mode (not on windows). This comment http://www.php.net/manual/en/reserved.variables.server.php#87195 from 2008 concurs. Zend and Symphony both seems to be happy to read even X- custom headers from SERVER without bothering with apace_request_headers() or anything like that. I have tried to read some SAPI code and while most of them are a bit obscure, to the best of my understanding at least nsapi.c copies every request header (ok, there are very few exceptions, but certainly doesnt care about custom ones). Thanks for pointing that out. Yes, I wrote that NSAPI code and the main idea was to reflect the HTTP_ server/env variables as Apache / CGI spec does. I know many other SAPIs don't take care and they are broken for lots of applications because of this. Insufficient knowledge on the APIs of those SAPIs prevented me from fixing it there, too. Apache SAPIs are safe, because they don't take care what variables to register, because they take what Apache itself uses as request variables (so it simply clones the Apache request environment). And those variables are the ones that everybody expect. To mimic Apache's behavior (which is also defined in CGI/1.1 spec, but optional only), I programmed the converter in the NSAPI SAPI that takes all request headers and transform them to CGI variables. It should also handle X- headers correctly (transformed to HTTP_X_). So... is this official enough that I can amend the reserved.variables.server.php and the function.apache-request-headers.php pages stating that every HTTP header including custom ones can be found In SERVER (with the odd security exceptions)? Theoretically that should be the case, but it isn't for most older SAPIs, which are partly unmaintained. Also, only NSAPI and ISAPI (as far as I know) mimic apache_request_headers, this is not part of SAPI spec. The function is not available in every SAPI. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.3.7pl1
+1 - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Saturday, August 20, 2011 1:17 AM To: PHP Internals Subject: [PHP-DEV] 5.3.7pl1 Hi! Looks like 5.3.7 shipped with broken crypt() (see bug# 55439 and http://svn.php.net/viewvc/?view=revisionamp;revision=315218) - and I think it's a serious problem since this means everybody's md5 passwords will stop working - so should we make 5.3.7pl1? And maybe not do these changes on 5.3, especially this close to the release? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
Yeah,
+1 for remove!
-
Uwe Schindler
theta...@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of Kalle
Sommer Nielsen
Sent: Wednesday, November 17, 2010 5:09 PM
To: Internals
Subject: [PHP-DEV] Magic quotes in trunk
Greetings
I wanted to raise this topic before we go Alpha with trunk, regarding our
beloved magic_quotes feature. There seems to be mixed opinions regarding
it
so I thought I would take it up for discussion.
We have advised people not to use magic_quotes, register_globals and the
like
for years, and they were marked as deprecated in 5.3.0+ if activated
through
their php.ini directives. Yet magic_quotes still is set to On in 5.3.0.
I think its
worth we either remove the feature or disable it in trunk as its a
security
related feature. Lets have a look at what each of those options means:
Removing magic_quotes):
Means we will remove the feature entirely in the source, we will throw an
E_CORE_ERROR if activated so people who have it enabled are forced to
disable it and make their applications work without magic_quotes.
This creates a minor issue for the hosts that simply disable it and have
their
customers applications run without them which can create a security risk
for
them, although it should be fairly limited. The functions to check for
magic_quotes_runtime should however stay for BC to avoid applications that
run on multiple versions of PHP from doing:
if(function_exists('...') ...)
Disabling them):
This will help to disable the spread of magic_quotes even more, and it can
safely be removed in the next major version of PHP.
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Secure SVN access
Hi anatoly, there problem is not only with SVN. In principle if a developer logs in to the PHP bug tracking system on http://bugs.php.net he also uses his password in plain text. Because of this, I see no difference here. I personally use a different password for PHP and no high-security one I use elsewhere. In general PHP is Open Source Software, if somebody misuses a PHP's developers passwords, all these changes can be reverted in SVN, so I see no problem. Additionally all commits are reviewed by the commit mailing list subscribers (all developers). - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: techto...@gmail.com [mailto:techto...@gmail.com] On Behalf Of techtonik Sent: Thursday, September 03, 2009 2:48 PM To: internals@lists.php.net Subject: [PHP-DEV] Secure SVN access Greeetings to php-core developers, Am I right that there is no https:// and svn+ssh:// access to svn.php.net repositories? If that's the case - how do you feel about sniffing developer's passwords? Please, CC. --anatoly t. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h
http://wiki.php.net/vcs/svnfaq Look for sparse checkouts. I forgot to post a howto for graphical SVN GUIs like TortoiseSVN, too. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Andrey Hristov [mailto:p...@hristov.com] Sent: Tuesday, August 25, 2009 5:24 PM To: Sebastian Bergmann Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h Sebastian Bergmann wrote: Andrey Hristov schrieb: Jani Taskinen wrote: This should propably be some FAQ somewhere, but please commit things in one single commit. (sparse checkouts rule! :) One single commit? I did commit at once. Jani meant one commit to update all three branches. ah, this is new to me, so far I haven't used SVN in collaboration with PHP. How do I commit to three branches (which are they ? 5.3, 6.0 and ?) when I can be in only one directory at a time - checkout of 5.3 or 6.0. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Renaming php-cvs to php-svn ?
Or just to something more generic like php-commits@ ? The same with zend-commits? Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Andrey Hristov [mailto:p...@hristov.com] Sent: Thursday, July 16, 2009 7:36 PM To: PHP Internals List Subject: [PHP-DEV] Renaming php-cvs to php-svn ? Hi, does it makes sense? Once we renamed php-dev to internals, so this won't be the first ML rename. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Soap over SSL and
As far as I know, SOAP does not use the HTTP wrappers directly, it uses only sockets/ssl for communication (so the context applies only to the lower level SSL socket). So CURL is not used, because PHP's HTTP streams are not used. - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: endrazine [mailto:endraz...@gmail.com] Sent: Friday, July 10, 2009 4:52 PM To: Hannes Magnusson Cc: David Zülke; PHP internals Subject: Re: [PHP-DEV] Soap over SSL and -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hannes Magnusson wrote: On Fri, Jul 10, 2009 at 16:38, endrazineendraz...@gmail.com wrote: David Zülke wrote: $c = new SoapClient( 'https://foo/bar.wsdl', array( 'stream_context = stream_context_create(array( 'ssl' = array( 'verify_peer' = true ) )) ) ); This works and solves the issue, thank you :) The other methods I have been suggested and have been testing, for instance recompiling with --with-curlwrappers do NOT work. --with-curlwrappers overwrites the builtin stream support to use curl. The curlwrappers have their own context options: http://php.net/context.curl -Hannes I verified it doesn't work. Regards, j- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXVagACgkQK/YAm7PYyblesgCcD25MfGepg4UslL/YYi+R0Yo9 Tu8An3hNn3ad3iXVsBK0fc/2BhqSkSTl =186g -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Throwing E_DEPRECATED on startup
I had the same this morning when I compiled PHP on my solaris machine. The php.ini from my system-wide lib folder was used for the tests. In my case it claimed about the deprecated *_long_arrays setting (or something like that). Almost no test worked until I edited my global php.ini. Tests should use a local php.ini in the build directory. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: paras...@gmail.com [mailto:paras...@gmail.com] On Behalf Of Daniel Brown Sent: Tuesday, June 30, 2009 11:31 PM To: Hannes Magnusson Cc: Kalle Sommer Nielsen; Internals Subject: Re: [PHP-DEV] Re: Throwing E_DEPRECATED on startup On Tue, Jun 30, 2009 at 16:30, Hannes Magnussonhannes.magnus...@gmail.com wrote: Now that 5.3.0 is out, are you looking into fixing run-tests.php or all tests? Like I warned about; if you enable any of these features in your php.ini and then run the test suite.. there are only a handful of tests that actually pass. Indeed. Going to install it on the CA2 mirror server this morning brought up a ton of failed and skip messages, which I mentioned to Hannes. Here's the grep'd output: r...@december [/dls/php/php-5.3.0]# make test | grep PASS PHP Warning: Directive 'magic_quotes_gpc' is deprecated in PHP 5.3 and greater in Unknown on line 0 PHP Warning: Directive 'magic_quotes_gpc' is deprecated in PHP 5.3 and greater in Unknown on line 0 PHP Warning: Directive 'magic_quotes_gpc' is deprecated in PHP 5.3 and greater in Unknown on line 0 PASS Error messages are shown [tests/run-test/test006.phpt] PASS Testing $argc and $argv handling (cli) [tests/basic/012.phpt] PASS Bug #28213 (crash in debug_print_backtrace in static methods) [tests/lang/bug28213.phpt] PASS Bug #39763 (filter applies magic_quotes twice in parse_str()) [ext/filter/tests/bug39763.phpt] PASS Test phpinfo() displays gettext support [ext/gettext/tests/gettext_phpinfo.phpt] PASS Bug #43293 (Multiple segfaults in getopt()) [ext/standard/tests/general_functions/bug43293_3.phpt] PASS Test get_magic_quotes_gpc() function [ext/standard/tests/general_functions/get_magic_quotes_gpc.phpt] PASS getopt [ext/standard/tests/general_functions/getopt.phpt] t] PASS getopt#002 [ext/standard/tests/general_functions/getopt_002.phpt] PASS getopt#003 [ext/standard/tests/general_functions/getopt_003.phpt] PASS getopt#004 (Optional values) [ext/standard/tests/general_functions/getopt_004.phpt] PASS getopt#005 (Required values) [ext/standard/tests/general_functions/getopt_005.phpt] FAIL Test parse_url() function: Parse a load of URLs without specifying PHP_URL_PASS as the URL component [ext/standard/tests/url/parse_url_basic_006.phpt] PASS Test phpinfo() displays xsl info [ext/xsl/tests/xsl-phpinfo.phpt] Test parse_url() function: Parse a load of URLs without specifying PHP_URL_PASS as the URL component [ext/standard/tests/url/parse_url_basic_006.phpt] r...@december [/dls/php/php-5.3.0]# uname -a Linux december.pilotpig.net 2.6.18-128.1.1.el5.028stab062.3 #1 SMP Tue May 5 17:31:34 MSD 2009 i686 i686 i386 GNU/Linux The rest of the 9,400+ tests all came back with undesired results. There were no other problems on any of the dev boxes I tried this morning, just the test results. -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Ask me about our fully-managed servers and proactive management clusters starting at just $200/mo.! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.3.0RC4
Hallo, I just wanted to compile PHP 5.3.0RC4 on my Solaris 10 box: panga...@pansrv1:~/install/php-5.3.0RC4$ gcc -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.5 and got a compilation failure: /bin/sh /pangaea/install/php-5.3.0RC4/libtool --silent --preserve-dup-deps --mode=compile gcc -I/pangaea/install/php-5.3.0RC4/ext -I -Iext/pdo_mysql/ -I/pangaea/install/php-5.3.0RC4/ext/pdo_mysql/ -DPHP_ATOM_INC -I/pangaea/install/php-5.3.0RC4/include -I/pangaea/install/php-5.3.0RC4/main -I/pangaea/install/php-5.3.0RC4 -I/pangaea/webserver70/include -I/pangaea/install/php-5.3.0RC4/ext/date/lib -I/pangaea/install/php-5.3.0RC4/ext/ereg/regex -I/opt/csw/include/libxml2 -I/opt/csw/include -I/pangaea/install/php-5.3.0RC4/ext/mbstring/oniguruma -I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl -I/pangaea/install/php-5.3.0RC4/ext/mbstring/libmbfl/mbfl -I/opt/csw/mysql5/include/mysql -I/usr/include/libxml2 -I/pangaea/install/php-5.3.0RC4/TSRM -I/pangaea/install/php-5.3.0RC4/Zend -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/opt/csw/include -g -O2 -DZTS -c /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c -o ext/pdo_mysql/mysql_statement.lo /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_dtor': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:52: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:70: error: structure has no member named `params' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:71: error: structure has no member named `params' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:73: error: structure has no member named `in_null' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:74: error: structure has no member named `in_null' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:76: error: structure has no member named `in_length' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:77: error: structure has no member named `in_length' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_set_row_count': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:127: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_execute': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:295: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_describe': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:678: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_get_col': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:727: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_col_meta': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:831: error: structure has no member named `stmt' /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c: In function `pdo_mysql_stmt_cursor_closer': /pangaea/install/php-5.3.0RC4/ext/pdo_mysql/mysql_statement.c:898: error: structure has no member named `stmt' gmake: *** [ext/pdo_mysql/mysql_statement.lo] Error 1 Is this a known bug? Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] Sent: Friday, June 19, 2009 10:51 AM To: internals@lists.php.net; php-gene...@lists.php.net Subject: [PHP-DEV] PHP 5.3.0RC4 Hello! we have packaged PHP 5.3.0RC4, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This this release candidate focused on bug fixes and stability improvements and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. We aim to release PHP 5.3.0 next week. In case of critical issues we will continue producing weekly RCs. For most users there will not be a noticeable change meaning that now is the time to really do the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your
RE: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
Hi Richard, I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly map into servers may have problems if using the wrong CRT. Until now, I had no time to build up a Windows Sun Java System Webserver and test it with both CRTs. The code compiles fine on the snaps box, but I am not sure, if the DLL loads into the server. To the snaps build: The NSAPI module tests for #define ZTS and does therefore not compile without thread safety. Why do the windows non-ts builds on snaps.php compile? Is ZTS on windows always defined (it looks like so in the makefile). How to test on windows, if thread safety is available? But better would be to disable thread-unsafe builds for the NSAPI SAPI from the beginning. Uwe - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Richard Quadling [mailto:rquadl...@googlemail.com] Sent: Wednesday, December 31, 2008 11:12 AM To: PHP Documentation ML; PHP Developers Mailing List Subject: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver. Hi. With regard to http://bugs.php.net/bug.php?id=46971, how much effort is needed (if any) to document that some functionality is not going to be available in all windows builds? [DOC] Or, When will VC6 be dropped? [CORE and DOC] Admittedly, it is only an issue for Microsoft SQL Server (mssql and pdo_mssql) and for Sybase_ct. With Microsoft having their own PHP extension for talking to MSSQL (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - though documented to only support SQL 2005 and 2008, not 7 or 2000), could this become the standard alternative for php_mssql.dll (though not PDO as the MS extension is procedural only, leaving ODBC as the route for older versions? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [INTERNALS-WIN] [REPOST] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
In general (this is why I also write to the internals list): DBLIB is no longer supported by Sybase, CT is preferred, according to Sybase. We are working with Sybase on this problem. I met them last year and we will get all SDKs, libs, docs or tools we will need to build sybase_ct for windows using VC9. Great, be sure to also check Sybase 12.5 CTLIB. A lot of servers and tools still run with Sybase 12.5. Or, you should write in the documentation, that it would be enough, to make copies of your Sybase 12.5 DLLS, with syb in the name (this is documented on Sybase homepage and the CTLIB documentation, but for the other way round: A .cmd script, that copies all DLLs to be able to run programs compiled with the old DLL names). If I can help, I have the Sybase 15 and 12.5 CTLIB headers and LIBS here, for some first tests. We have contacts to Sybase Germany (we are the biggest *educational* customer in Germany, see http://www.sybase.com/detail?id=1052607), maybe we can help. If using CTLIB, you are also able to use the Sybase Data Warehouse (Sybase IQ). I never got this working correctly with FreeTDS. On the other hand: I prefer to use ODBC on windows and also UNIX, this makes life a little bit simplier. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] json_encode()
As is noted in an earlier mail, I would prefer 1 (simply document it in the function description). In my opinion, if somebody then passes a basic type to json_encode he is aware of what he is doing (hopefully). For compatibility with current code and securely escaping strings for javascript it is the best. - Uwe Schindler theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Monday, December 15, 2008 6:50 PM To: PHP Developers Mailing List Subject: [PHP-DEV] json_encode() Ok, so as promised I ran some of the options we have that came up last week by Douglas Crockford. 1. Document the fact that if you want to strictly conform to the JSON spec and be sure your json_encode output will work in various JSON parsers, you have to pass it a PHP array or object. 2. Remove support for basic types entirely and throw an error if you pass json_encode() something that is not an array or an object. 3. Wrap basic types in an array [] by default and perhaps add an option to json_encode() to skip the wrapper. He would prefer option 1. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Removing basic types from our JSON parser
script var foo = ?php echo json_encode($foo)?; /script will always work. The only question is what sort of variable foo will end up being. The RFC says we have to wrap basic types in an array or object, while currently we let the basic types through without the wrapper. He problem her eis: A lot of people use in a way and assume, that a basic type is serialized as a basic type in JSON/JS. If we change this, it could break a lot of apps. And the above is really nice to encode PHP strings to a secure JS variant. It is hard to do with addslashes etc. So I think, we should not change the way it works currently. I think in the docs for json_encode() should be a warning: JSON officially only supports Objects and Arrays as outer/top-level/... type for JSON serializations. So the argument of json_encode must be a PHP object or array to be fully JSON conformant. If you provide a simple type (string, number, Boolean), json_encode will generate a valid java script, but some conformant JSON parser may not be able to read it. How about this? Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Removing basic types from our JSON parser
For reference I saw people use json_encode() to pass a string to javascript into their page while avoiding bugs/XSS with stuff like /script. var foo = ?=json_encode($my_string)?; ... (yes, they maybe heared somewhere that JSON is *not* javascript, I told 'em too). This is not correct. JSON *is* valid JavaScript, but the other way round is not correct. Not every Javascript is JSON. So it is perfectly legal, to do this. I think, this is really cool, using json_encode() as something like htmlspecialchars for correctly encoding strings inside JS for security. I use it, too. To the problem with basic types: I like the way of maybe giving a option to the function. If you want to be standards conformant, you have to remove the encoding parameter (which is also there), too. JSON has to be UTF-8, if you want to be conform to the specs. But for the example above (secure encoding of JS strings with json_encode), it is perfectly legal to use another encoding (in the above case, the encoding of the HTML page). Uwe -- 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()
Hallo Arnaud,
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 ;)
That is correct, you are able to remove the headers. For removing the Date
header it would be enough to just use the header_remove() without setting it
before. But if somebody does this, he knows what he is doing. I want to
prevent PHP from doing things that the user cannot control or understand.
Sun Webserver for example is able to compress output automatically and other
things. So I am not sure what happens, if you remove headers. As source code
of this webserver is not yet available (Sun wants to release it soon), I do
not know *when* nsapi puts entries in his internal header hash table. Maybe
its in protocol_start_response(), if so everything would be ok, and I can
manually cleanup the complete webserver's hash table (solution b). But
nsapi_response_headers from PHP called shows, that e.g. Date and Server are
set *before* the request starts.
In my opinion, a call to header_remove() from PHP should only remove headers
set by PHP (e.g. revert to the state, before the PHP script started).
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.
That's not correct for at least apache:
php_apache_sapi_flush(void *server_context)
{
...
sapi_send_headers(TSRMLS_C);
r-status = SG(sapi_headers).http_response_code;
SG(headers_sent) = 1;
if (ap_rflush(r) 0 || r-connection-aborted) {
php_handle_aborted_connection();
}
}
The flush function just calls sapi_send_headers so it explicitely send the
headers, so my approach of do not implementing a header_handler would also
correctly send the headers in this case. For NSAPI it is not even possible
to send headers explicitely, you can only set them in an internal hashtable
of the web server.
For a typical NSAPI module the workflow is the following:
Any Service handler from webserver's config sets headers in the internal
hash table. Before it starts to write output, it may also set the response
code. All this is not sent to the client immediately. The headers and
everything is sent on protocol_start_response(). After that you cannot set
any headers anymore and you have to write to the output stream.
The PHP module calls the webserver's protocol_start_response() in
sapi_send_headers(), so even when you flush, this must be called (in the
current version of output buffering there is still a bug about this, which
is fixed in the new version, I think). I repaired this by also implementing
flush for nsapi in my new version, which calls like apache
sapi_send_headers(TSRMLS_C). This fixes a very old bug for NSAPI.
So in my opinion for the server it is no difference when to set the headers
(immediately after the call to header()) or shortly before starting the
reponse. And this is how CGI works - and this would be enough for NSAPI,
too.
The only thing that would not work is explicitely removing headers like
Date:, but for this use case header_handler() could only be implemented
for the op SAPI_HEADER_DELETE. But with CGI this would not be possible.
Uwe
--
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()
I implemented and tested now version a), works fine! header_remove() now
only removes headers set/modified by PHP.
I tested the case to remove *all* headers by cleaning the server's header
hash table, but this breaks server hard:
Best example: Removing the Transfer-encoding: chunked header, the server
inserts at the beginning of the request before PHP is executed, is not
restored on protocol_start_response, but the server still sends chunked data
- the browser will not understand it.
Solutions c), as I told before would also be good, but then you would not
see PHP's headers in get_response_headers(). And code is not much shorter or
simplier.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Uwe Schindler [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 29, 2008 1:09 PM
To: 'Arnaud Le Blanc'
Cc: 'Lukas Kahwe Smith'; internals@lists.php.net; 'Christian Schmidt';
'Alex Leigh'; 'George Wang'
Subject: RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set
usingheader()
Hallo Arnaud,
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 ;)
That is correct, you are able to remove the headers. For removing the Date
header it would be enough to just use the header_remove() without setting
it
before. But if somebody does this, he knows what he is doing. I want to
prevent PHP from doing things that the user cannot control or understand.
Sun Webserver for example is able to compress output automatically and
other
things. So I am not sure what happens, if you remove headers. As source
code
of this webserver is not yet available (Sun wants to release it soon), I
do
not know *when* nsapi puts entries in his internal header hash table.
Maybe
its in protocol_start_response(), if so everything would be ok, and I can
manually cleanup the complete webserver's hash table (solution b). But
nsapi_response_headers from PHP called shows, that e.g. Date and Server
are
set *before* the request starts.
In my opinion, a call to header_remove() from PHP should only remove
headers
set by PHP (e.g. revert to the state, before the PHP script started).
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.
That's not correct for at least apache:
php_apache_sapi_flush(void *server_context)
{
...
sapi_send_headers(TSRMLS_C);
r-status = SG(sapi_headers).http_response_code;
SG(headers_sent) = 1;
if (ap_rflush(r) 0 || r-connection-aborted) {
php_handle_aborted_connection();
}
}
The flush function just calls sapi_send_headers so it explicitely send the
headers, so my approach of do not implementing a header_handler would also
correctly send the headers in this case. For NSAPI it is not even possible
to send headers explicitely, you can only set them in an internal
hashtable
of the web server.
For a typical NSAPI module the workflow is the following:
Any Service handler from webserver's config sets headers in the internal
hash table. Before it starts to write output, it may also set the response
code. All this is not sent to the client immediately. The headers and
everything is sent on protocol_start_response(). After that you cannot set
any headers anymore and you have to write to the output stream.
The PHP module calls the webserver's protocol_start_response() in
sapi_send_headers(), so even when you flush, this must be called (in the
current version of output buffering there is still a bug about this, which
is fixed in the new version, I think). I repaired this by also
implementing
flush for nsapi in my new version, which calls like apache
sapi_send_headers(TSRMLS_C). This fixes a very old bug for NSAPI.
So in my opinion for the server it is no difference when to set the
headers
(immediately after the call to header()) or shortly before starting the
reponse. And this is how CGI works - and this would be enough for NSAPI,
too.
The only thing that would not work is explicitely removing headers like
Date:, but for this use case header_handler() could only be implemented
for the op SAPI_HEADER_DELETE. But with CGI this would not be possible.
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
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] [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] Can someone explain me why this happens please?
This is per definition: In C local variables are not initialized with anything!
The weird characters you see are content from prior memory usage leftover from
calls to other functions. Its just garbage. In C, local variables must always
be initialized.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Chris Jiang [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 16, 2008 2:36 PM
To: internals@lists.php.net; M. Karpelès
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Can someone explain me why this happens please?
Ah, greet appreciation! The memset() way works perfectly, but the res[0]
way didn't work.
Beside, I think you are right. Although I'm just a beginner in C
language, but from the experience of JS and PHP, also according to the
document I've been searching all the time, there should be something
related to time.h functions which might be more suitable for what I'm
doing. However, at the mean time, I'm just trying to get 'strings' to
work in C and Zend, hehe!
Still, this is a really strange experience. Where are those characters
come from? Shouldn't it be a clean array when I first created them?
Anything related to the zval structure?
Thank you again!
M. Karpelès wrote:
Hi,
Try initializing your res variable first.
either:
memset(res, 0, sizeof(res));
Or:
res[0] = 0;
Both will work, it all depends if you want to write clean code, of
fast code (and your definition of both).
I believe there are cleaner way to do what you are doing, but I'll let
that to your curiosity.
Mark
Le dimanche 16 novembre 2008 à 21:15 +0800, Chris Jiang a écrit :
Hi all, since I started playing around with Zend API, I thought it
would
be better to start writing some small functions as practice. Then my
entire weekend became nightmare.
I've tried to add a function activated in dynamic module, and it gives
a
very strange result. This function is really simple: taking an integer
as argument, returns a ':mm:ss' format string. If additional
argument (BOOL) is set to true, then the '' will turn to 'DD hh'.
Now, it works fine while compiled with GCC alone in standard C style,
but while working as a PHP function, the result is like this:
(!靠备h2339:44:05
(!靠备窵▒97D 11:44:05
What are the characters in front of them? Where did they come? It's
really confusing..
The original Zend style code is as follow:
ZEND_FUNCTION(cj_format_clock)
{
char res[50], myb[10];
long mys = 0;
double myd, myh, mym;
zend_bool useDay = 0;
if ( zend_parse_parameters_ex(ZEND_PARSE_PARAMS_QUIET,
ZEND_NUM_ARGS()
TSRMLS_CC, l|b, mys, useDay) == FAILURE )
{
php_error(E_ERROR, Expecting
cj_format_clock([(INT)seconds]),
get_active_function_name(TSRMLS_C));
return;
}
if ( mys 0 )
{
php_error(E_ERROR, Number of second must be a possitive
integer,
get_active_function_name(TSRMLS_C));
return;
}
if ( useDay )
{
myd = mys / 86400;
mys %= 86400;
sprintf(myb, %.0f, myd);
strcat(res, myb);
strcat(res, D );
}
myh = mys / 3600;
mys %= 3600;
if ( myh 10 )
strcat(res, 0);
sprintf(myb, %.0f, myh);
strcat(res, myb);
strcat(res, :);
mym = mys / 60;
mys %= 60;
if ( mym 10 )
strcat(res, 0);
sprintf(myb, %.0f, mym);
strcat(res, myb);
strcat(res, :);
if ( mys 10 )
strcat(res, 0);
sprintf(myb, %d, mys);
strcat(res, myb);
RETURN_STRING(res, 1);
}
Hi,
Try initializing your res variable first.
either:
memset(res, 0, sizeof(res));
Or:
res[0] = 0;
Both will work, it all depends if you want to write clean code, of
fast code (and your definition of both).
I believe there are cleaner way to do what you are doing, but I'll let
that to your curiosity.
Mark
Le dimanche 16 novembre 2008 à 21:15 +0800, Chris Jiang a écrit :
Hi all, since I started playing around with Zend API, I thought it
would
be better to start writing some small functions as practice. Then my
entire weekend became nightmare.
I've tried to add a function activated in dynamic module, and it gives
a
very strange result. This function is really simple: taking an integer
as argument, returns a ':mm:ss' format string. If additional
argument (BOOL) is set to true, then the '' will turn to 'DD hh'.
Now, it works fine while compiled with GCC alone in standard C style,
but while working as a PHP function, the result is like this:
(!靠备h2339:44:05
(!靠备窵▒97D 11:44:05
What are the characters in front of them? Where did they come? It's
RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
+1
I have no problem with implementing this for NSAPI after the patch is
committed to CVS, just keep me informed about this.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Arnaud LB [mailto:[EMAIL PROTECTED] On Behalf Of Arnaud Le Blanc
Sent: Sunday, November 09, 2008 10:02 PM
To: internals@lists.php.net
Cc: Christian Schmidt
Subject: Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set
usingheader()
On Sunday 09 November 2008 19:51:31 Christian Schmidt wrote:
Stan Vassilev | FM wrote:
I suggest header_remove('*') or simply header_remove() /no param/
removes all headers (including the one PHP sets by default), so we can
start with a clear state.
I added header_remove('Foo'). header_remove() without arguments removes
all headers (though Apache still adds some headers that you cannot
remove).
I have tested with apache2handler and cgi. I had to change the signature
of SAPI header_handler function and sapi_header_struct, so the other
SAPIs should be updated for this. I am not sure how to test all these?
Creating a testing environment for all those webservers seems like a
huge task.
I am not comfortable with the size of this patch, given my understanding
of the PHP source code and my general C skills, so I am posting this
patch hoping that somebody will pick it up or help me get it into shape.
It looks good. The signature change is not that bad if it forces all SAPIs
to
be updated and ensures that PHP behaves the same way with all SAPIs.
It is also possible to add something like header_delete_handler() or
header_handler_ex() to sapi_module_struct if the signature change is to be
avoided.
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS
I do not know exactly how this will behave with other web servers. I do the module for Sun Java System Webservers (NSAPI) which normally uses pthreads (on Solaris, Linux) but not on AIX (this is why PHP as NSAPI module does not work on AIX). The correct way for this webserver would be to use the macros/functions from the NSAPI library to handle threads, which is implemented in TSRM [see #ifdef NSAPI], but never used, because when compiling PHP the NSAPI defines are only known to the NSAPI module, but not to the whole source tree - so TSRM uses pthreads (which is clear then). The parallel CLI version of PHP compiled with NSAPI threads would not work, too (if not using pthreads). But for newer SJSWS servers, this is not a problem, if PHP's NSAPI always uses pthreads - only AIX is broken (but this since years). So: may there be issues with this server, too? I would like to test it, too, but I need to eventually add code to sapi/nsapi, you may help me :) - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 7:00 AM To: Andi Gutmans Cc: PHP Development Subject: Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS Hi, Yes, I have looked for the issue with --with-tsrm-full-__thread-tls and there are effectively some issues. When building PIC code, the used TLS model is a static model which does not allow modules to be loaded at run-time. glibc's dlopen() sometimes allow such code to be loaded at runtime when it finds some free memory, that's why -- with- tsrm-__thread-tls works, but it is not expected to always work. So when building PIC code that's expected to work only when the server/application links the PHP module, or when using LD_PRELOAD, etc. Building non-PIC code allows to use a dynamic TLS model, which allows to load modules a run-time, but it is less efficient (4.8s in bench.php, still faster than unpatched version, even non-PIC, but less efficient). Regards, Arnaud On Tuesday 19 August 2008 06:18:51 Andi Gutmans wrote: Hi Arnaud, I remember that at the time we looked at thread local storage and there were some real issues with it. I can't remember what as it was about 7+ years ago. I will ask Zeev if he remembers and if not search my archives (don't have years prior to 2007 indexed :'( ). Andi -Original Message- From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2008 7:19 PM To: PHP Development Subject: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS Hi, Currently the way globals work forces to pass a thread-local-storage pointer across function calls, which involves some overhead. Also, not all functions get the pointer as argument and need to use TSRMLS_FETCH(), which is slow. For instance emalloc() involves a TSRMLS_FETCH(). An other overhead is accessing globals, using multiple pointers in different locations. The following patch caches each global address in a native TLS variable so that accessing a global is as simple as global_name-member. This removes the requirement of passing the tls pointer across function calls, so that the two major overheads of ZTS builds are avoided. Globals can optionally be declared statically, which speeds up things a bit. Results in bench.php: non-ZTS: 3.7s ZTS unpatched:5.2s ZTS patched: 4.0s ZTS patched and static globals: 3.8s The patch introduces two new macros: TSRMG_D() (declare) and TSRMG_DH() (declare, for headers) to declare globals, instead of the current ts_rsrc_id foo_global_id. These macros declare the global id, plus the __thread pointer to the global storage. ts_allocate_id now takes one more callback function as argument to bind the global pointer to its storage. This callback is declared in TSRMG_D[H](). As all TSRMLS_* macros now does nothing, it is needed to call ts_resource(0) explicitly at least one time in each thread to initialize its storage. A new TSRMLS_INIT() macro as been added for this purpose. All this is disabled by default. --with-tsrm-__thread-tls enables the features of the patch, and --with-tsrm-full-__thread-tls enables static declaration of globals. It as been tested on Linux compiled with --disable-all in CLI and a bit in Apache2 with the worker MPM. Known issues: - Declaring globals statically (--with-tsrm-full-__thread-tls) causes troubles to dlopen(), actually Apache wont load the module at runtime (it works with just --with-tsrm-__thread-tls). - The patch assumes that all resources are ts_allocate_id()'ed before any other thread calls ts_allocate_id or ts_resource_ex(), which
RE: [PHP-DEV] passing Cookies and other environment stuff to PHP SAPI Embed
If you want to start PHP scripts in an own http server, the best way would
be to create a SAPI for it. SAPIs only have to implement callbacks for the
PHP engine to write stuff to the output stream, read input stream in POST
requests and populate variables and output headers. The embed SAPI is a
striiped down SAPI to make it simplier to embed PHP in applications outside
webservers, so EMBED implements all these features in a minimalistic way to
get scripts running.
My opinion: Use another SAPI module as entry point and write your own SAPI
code. I am the maintainer of NSAPI SAPI, I could help you, if needed.
Uwe
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 3:50 PM
To: internals@lists.php.net
Subject: [PHP-DEV] passing Cookies and other environment stuff to PHP SAPI
Embed
Hi
I'm trying to write the php processing part of a small httpd. I want to
use
the SAPI Embed for interpreting php scripts. But I can't find a way to
specify the content of variables like $_COOKIE, $_REQUEST, $_SERVER etc.
Is there any function to initalize the SAPI header with all this stuff?
That's what my little programm looks like at the moment:
cpp
#include php_embed.h
#include iostream
#include string
using namespace std;
string output = ;
int store_string (const char *str, unsigned int str_length TSRMLS_DC)
{
if(strlen 0)
output += str;
return SUCCESS;
}
int main(int argc, char* argv[])
{
// pass output of script to store_string() instead of printing it to
stdout
php_embed_module.ub_write = store_string;
PHP_EMBED_START_BLOCK(argc, argv)
// php_request_startup(TSRMLS_C);
sapi_header_struct *h;
zend_llist_position pos;
zval retval; // return value
// execute script
zend_eval_string(include 'test.php';, retval, script TSRMLS_CC);
cout \nscript output:\n output endl;
// convert retval to long
convert_to_long(retval);
cout \nretval: Z_LVAL(retval) endl;
// free memory
zval_dtor(retval);
cout \nreading header: endl;
// get header (SG = SAPI Globals)
sapi_headers_struct *sapi_headers = (SG(sapi_headers));
// read first element (= header line)
h = (sapi_header_struct*)zend_llist_get_first_ex(sapi_headers-
headers, pos);
// while existing elements
while (h)
{
// print them
cout h-header endl;
// get next element
h = (sapi_header_struct*)zend_llist_get_next_ex(sapi_headers-
headers, pos);
}
PHP_EMBED_END_BLOCK()
return 0;
}
/cpp
Before calling zend_eval_string() to interpret the script there has to be
some way to pass all the client information like Cookies and stuff to the
SAPI, but I can't find a way to do this. Unfortunately there is no
documentation at all for this API.
Is there anyone who could give me some hints, or a small code snippet?
Regards,
Alex
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
As of php 5.3, it is possible to have a per directory configuration, either using the system php.ini or using a .htaccess-like php.ini (.user.ini). The concept is based on what you have in htscanner but in a much better way (same syntax than in any php.ini). The goal is to enable this feature in all SAPIs. I am sure the new per directory configuration should work with LiteSpeed SAPI. However, if it needs to scan each directory repeatedly for each request, it will slow down PHP even further. It is cached using a user defined ttl. Hi Pierre, How do I enable another SAPIs for this per-dir ini files? How are they named? Found no documentation about it. I would like to upgrade my NSAPI module (Sun Webservers) for it. As Sun Webservers do not know .htaccess files, PHP is hard to configure for specific directories (it is possible, but you must map all ini entries as extra parameters in the php5_execute NSAPI call, which can be made per-dir, in the central config files). A per-dir config by magic files like .php.ini in script folder would be good. Is there a generic solution for SAPIs? Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
Is there a generic solution for SAPIs? The stuff is pretty generic, just check how it's done for sapi/cgi/cgi_main.c in function sapi_cgi_activate(). (IIRC :) I think I even put some comments in there.. Yes, looks good. Even the host-based config could be enabled by NSAPI. The code looks very generic and could be put directly into a generic SAPI function that runs after register_variables. You only need then _SERVER['DOCUMENT_ROOT'] (the length) and the script filename and HTTP_HOST/SERVER_NAME which is registered by every SAPI. One problem is in the per dir user config code: If one maps an alias for a directory containing the PHP scripts into his webserver config, the document root may not be a substring of the script file name, which would be a problem for the user config loading algorithm... You put the code into activate, but it may also be possible to do all this in the request startup I think...? I think we should discuss this in an extra thread. I would be happy to help with a generic solution (e.g. before script startup) and would help in implementing it! Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
but it may also be possible to do all this in the request startup I think...? I don't like the idea to keep adding stuff in request startup, at least, please make it optional. The overhead for request startup and cleanup have becoming higher and higher, which make PHP become slower and slower, especially for simple request like a Hello World request, it put PHP into a less competitive position when benchmark with other scripting languages. I wish I could do something in that regarding in the future, at least for our LiteSpeed SAPI if others does not like it. The code in CGI is called in sapi_activate, which is called from php_request_startup() just before the scripts starts. In this stage you can choose the right config (e.g. from the cache) by using the script directory as entry in has table or something like that. You do not need to search for config files in a whole directory tree below DOCUMENT_ROOT and the script directory every time. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_ini.c
That would be a solution. The only thing is that this would be a break in BC for extensions using zend_alter_ini_entry. I will test your patch with my webserver together with the @-Operator. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 2:06 PM To: Stanislav Malyshev Cc: internals@lists.php.net Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_ini.c Sorry for the top posting Derick. :) Stas, this patch solves the problems with @ and doing php_admin_value error_reporting some value: http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch I renamed zend_alter_ini_entry() to zend_alter_ini_entry_ex() and added one more parameter to force change regardless of the modifiable value. --Jani On Mon, 2007-09-03 at 15:20 +0300, Jani Taskinen wrote: See the 2nd last comment (by [EMAIL PROTECTED]): http://bugs.php.net/bug.php?id=41561 The handling of the @ operator is the issue here. Shouldn't that be turned on/off without touching the INI stuff anyway? (I mailed about this earlier too, nobody bothered to reply..) --Jani On Fri, 2007-08-31 at 10:27 -0700, Stanislav Malyshev wrote: Could you explain what was the problem and how it was solved? Jani Taskinen wrote: janiFri Aug 31 07:52:09 2007 UTC Modified files: /ZendEngine2zend_ini.c Log: - Revert the revert: this is not causing any problems (or we have lot bigger issues), the bug is elsewhere -- Make me happy: http://pecl.php.net/wishlist.php/jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php5 as universal binary (Mac OS X)
Hi Antony, the problem is that my VMWare-patched MacOSX is corrupt. I have to reinstall it and also install XCode. And my official Mac is a PowerPc one that cannot create universal binaries. It could be better for a fast answer to ask the person (Christian Speich) who originally asked for help to test your patch. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Antony Dovgal [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 11:06 AM To: Uwe Schindler Cc: internals@lists.php.net Subject: Re: [PHP-DEV] php5 as universal binary (Mac OS X) Uwe, could you plz test this patch? http://dev.daylessday.org/diff/macos_uni.diff Thanks. On 27.07.2007 16:21, Uwe Schindler wrote: On http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/co mp iling/chapter_4_section_3.html Apple states: -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: ... checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files ./configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: ... configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Hello again, got it configured on Solaris with bash configure The following two things are problematic: 1) @-operator before function names does not suppress warning messages anymore? Whats wrong? I got for example messages like cannot open file... even when it was opened with @fopen(...). 2) make test is broken: [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ gmake test Build complete. Don't forget to run 'make test'. /bin/sh: syntax error at line 1: `;' unexpected gmake: [test] Error 2 (ignored) - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? How can I find that out? Is there a debug parameter? Config.log does not show anything. Could it be that on your solaris system the default shell in /bin/sh is bash? It's definitely not bash (cause I have to run bash manually to get a usable shell). # ls -l /bin/sh -r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /bin/sh lrwxrwxrwx 1 root root 13 Apr 13 10:40 /bin/sh - ../../sbin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /sbin/sh -r-xr-xr-x 1 root root 82468 Oct 18 2006 /sbin/sh Until now, I have no error location. I think I will look into the changes in configure.in and look for test calls and try to modify them. Starting configure with sh -v did not work it only prints a few messages at beginning but then switches to another shell (???). The problem is fixed if you start configure with bash configure. But it would be good to fix this. You are right with CLI it works. But there seems to be a problem with INI parsing. The web application that produced this error was started with an overwritten error_reporting value running in Sun Java System Webserver which worked correctly with 5.2.3: Service fn=php5_execute type=magnus-internal/x-httpd-php error_reporting=2039 allow_url_include=1 This works just fine either: ./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen(, r); No idea how the sun webserver passes options to PHP, though. I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I think I write now a bug report and paste this mail conversation into it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Hallo Jani, thanks, the configure error is gone! gmake test still fails with /bin/sh: syntax error at line 1: `;' unexpected - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:48 PM To: Uwe Schindler Subject: RE: [PHP-DEV] 5.2.4RC1 Released I changed one added 'test' line in acinclude.m4 and committed it..so try the latest PHP_5_2 checkout. --Jani On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: .. checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: .. configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:48, Uwe Schindler wrote:
How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.
It is not global. The overwritten value is set only for a specific path
(you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).
The changed value then corrupts the ini entry complete. I found out why
this
is so, so this is a _bug_.
The following patch, when reverted fixes it and restores the old
behaviour:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.
39
.2.2.2.9pathrev=PHP_5_2
It's done to prevent overwriting settings set in httpd.conf (aka
php_admin_value's).
I know how this is meant. But without the added patch, it does not corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded one),
because it modifies the ini setting in a way that affects later running
threads.
I try to find a way to reproduce it in other webservers.
This is the code that NSAPI uses to modify the INI entries:
entry-param-name is the nullterminated ini key name, entry-param-value
is the nullteminated value. This code runs on every request (like in apache
a php_(admin)_value) that needs to set some specific ini-values. The server
runs only *one* process that handles all requests in its lifetime because it
is multithreaded:
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
. It is always runned with admin privileges because SJSWS does not have
htaccess files. The big advantage to have the possibility to set ini values
is, that it is not server-wide you can change the call to PHP SAPI e.g. per
virtual server or URI path (see documentation of NSAPI).
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... I attached a patch. This patch must be applied in all cases. A second thing is to remove breakage of the @ operator. Oh I forgot, this does not help, too. Because the ADMIN-only status given by antonys patch (change of ini_entry-modifiable) is not rolled back after request shutdown. For the Apache-Not-Multithreaded people a description of the problem: An Apache server administrator has 2 virtual servers: * One with the original php.ini configuration and no php_admin_values. * One with a modified value that is set by php_admin_value. The setting is overwritten on the first request of the second virtual server. This is ok, because the value is restored after the request finishes. But the problem is that Antonys patch marked the flag as admin only, which is not reverted at end of request. The first virtual server without the php_admin_value will also have the ini-setting marked as ADMIN only until end of time :( Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote:
This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.
Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).
The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.
The problem with the original fix of antony was the same: The first time
any
thread started to modify any INI entry it was marked as admin-only for
the
whole PHP server until a restart and it stayed in that state because the
flag was changed *before* the hash table was replicated. This is a second
bug. So at least the lines of antony must moved a few lines down in
code...
I attached a patch. This patch must be applied in all cases. A second thing
is to remove breakage of the @ operator.
Uwe
Index: zend_ini.c
===
RCS file: /repository/ZendEngine2/zend_ini.c,v
retrieving revision 1.39.2.2.2.10
diff -u -r1.39.2.2.2.10 zend_ini.c
--- zend_ini.c 17 Jun 2007 14:31:12 - 1.39.2.2.2.10
+++ zend_ini.c 3 Aug 2007 14:46:30 -
@@ -243,10 +243,6 @@
return FAILURE;
}
- if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
- ini_entry-modifiable = ZEND_INI_SYSTEM;
- }
-
if (!(ini_entry-modifiable modify_type)) {
return FAILURE;
}
@@ -264,6 +260,10 @@
zend_hash_add(EG(modified_ini_directives), name, name_length,
ini_entry, sizeof(zend_ini_entry*), NULL);
}
+ if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
+ ini_entry-modifiable = ZEND_INI_SYSTEM;
+ }
+
duplicate = estrndup(new_value, new_value_length);
if (!ini_entry-on_modify
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I reopened the original bug reported that lead to your change.
At the moment I am trying to fix that. I moved your code a few lines down in
zend_alter_ini_entry but until now with no success.
I suppose there is something special with error reporting that corrupts it.
It seems that it does not like it to be changed to ZEND_INI_SYSTEM because
the @operator tries to change the value (e.g. in zend_vm_execute.h), which
fails silently:
static int ZEND_BEGIN_SILENCE_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
zend_op *opline = EX(opline);
Z_LVAL(EX_T(opline-result.u.var).tmp_var) = EG(error_reporting);
Z_TYPE(EX_T(opline-result.u.var).tmp_var) = IS_LONG; /* shouldn't
be necessary */
if (EX(old_error_reporting) == NULL) {
EX(old_error_reporting) =
EX_T(opline-result.u.var).tmp_var;
}
if (EG(error_reporting)) {
zend_alter_ini_entry(error_reporting,
sizeof(error_reporting), 0, 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 3:15 PM
To: Uwe Schindler
Cc: 'Ilia Alshanetsky'; 'PHP Internals'
Subject: Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 16:04, Uwe Schindler wrote:
I know how this is meant. But without the added patch, it does not
corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded
one),
because it modifies the ini setting in a way that affects later running
threads.
Ok, I see.
Please fill a bug report and assign it to me, I'll deal with it.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 10:32, Uwe Schindler wrote:
Configuring on Solaris (2.10) no longer works, ist the old problem with
test that is more strict on solaris:
...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
Generating files
./configure: test: argument expected
[EMAIL PROTECTED]:~/install/php-5.2.4RC1$
Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?
How can I find that out? Is there a debug parameter? Config.log does not
show anything.
Could it be that on your solaris system the default shell in /bin/sh is
bash?
The following two things are problematic:
1) @-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like cannot open file... even when it was
opened with @fopen(...).
Not reproducible either.
./sapi/cli/php -r 'fopen(a, r);'
Warning: fopen(a): failed to open stream: No such file or directory in
Command line code on line 1
./sapi/cli/php -r '@fopen(a, r);'
silence
You are right with CLI it works. But there seems to be a problem with INI
parsing. The web application that produced this error was started with an
overwritten error_reporting value running in Sun Java System Webserver
which worked correctly with 5.2.3:
Service fn=php5_execute type=magnus-internal/x-httpd-php
error_reporting=2039 allow_url_include=1
Removing the error_reporting fixed the problem. Was there a change somewhere
that error_reporting with 2039 set by...
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
...may not work? Just for interest, I am sure that this NSAPI option was not
correct because it was a relict from former days.
I removed the wrong error reporting now, but it is interesting that the same
value worked before.
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. It is not global. The overwritten value is set only for a specific path (you can be sure that I know how Sun Webserver works, I maintain the NSAPI module... :-) ). The changed value then corrupts the ini entry complete. I found out why this is so, so this is a _bug_. The following patch, when reverted fixes it and restores the old behaviour: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.39 .2.2.2.9pathrev=PHP_5_2 I do not know why, but it seems that this request specific code tries to overwrite the definition of the ini entry and corrupts it in a ZTS environment. After that every request this webserver handles (even when not affected by a overwritten value produces nice error messages. Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? Take Apache on Windows... :) I doid not want to ask you alone, the mail was to [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php5 as universal binary (Mac OS X)
On http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/comp iling/chapter_4_section_3.html Apple states: However, applications that make configuration-time decisions about the size of data structures will generally fail to build correctly in such an environment (since those sizes may need to be different depending on whether the compiler is executing a ppc pass, a ppc64 pass, or an i386 pass). When this happens, the tool must be configured and compiled for each architecture as separate executables, then glued together manually using lipo(1). In rare cases, software not written with cross-compilation in mind will make configure-time decisions by executing code on the build host. In these cases, you will have to manually alter either the configuration scripts or the resulting headers to be appropriate for the actual target architecture (rather than the build architecture). In some cases, this can be solved by telling the configure script that you are cross-compiling using the --host, --build, and --target flags. However, this may simply result in defaults for the target platform being inserted, which doesn't really solve the problem. The best fix is to replace configure-time detection of endianness, data type sizes, and so on with compile-time or run-time detection. For example, instead of testing the architecture for endianness to obtain consistent byte order in a file, you should do one of the following: * Use C preprocessor macros like __BIG_ENDIAN__ and __LITTLE_ENDIAN__ to test endianness at compile time. * Use functions like htonl, htons, ntohl, and ntohs to guarantee a big-endian representation on any architecture. * Extract individual bytes by bitwise masking and shifting (for example, lowbyte=word 0xff; nextbyte = (word 8) 0xff; and so on). Similarly, instead of performing elaborate tests to determine whether to use int or long for a 4-byte piece of data, you should simply use a standard sized type such as uint32_t. So a good test would be to check if one of both macros is defined and its an apple gcc: #if (defined(__APPLE__) || defined(__APPLE_CC__)) (defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)) # undef WORDS_BIGENDIAN # define WORDS_BIGENDIAN __BIG_ENDIAN__ #endif If gcc is not the apple one the configure value is used. If it is an apple one, but a very old one neither BIG or LITTLE endian is defined, which also lets configure test it. But if one of both is defined then we can rely on the macros. Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] -Original Message- From: Antony Dovgal [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 12:32 PM To: Uwe Schindler Cc: internals@lists.php.net Subject: Re: [PHP-DEV] php5 as universal binary (Mac OS X) On 27.07.2007 14:23, Uwe Schindler wrote: The simpliest would be to create a patch that is included *after* the configure-generated .h file. I do not exactly now, in which PHP/Zend specific .h file the configure generated php_config.h one is included, but that would be the place to place the following macro: #if defined(MACOSX) (I do not know the exact macro for detecting osx) # undef WORDS_BIGENDIAN # define WORDS_BIGENDIAN __BIG_ENDIAN__ #endif I'm not completely sure it's ok when you're NOT compiling a universal binary. Also the __BIG_ENDIAN__ constant my not exist IIRC. But the main reason of course is the fact that the patch I use works just fine and I'm not relly interested in debugging something that isn't broken for me. If you are - feel free to spend some time on this issue, I'd help you where I can. -- Wbr, Antony Dovgal
RE: [PHP-DEV] php5 as universal binary (Mac OS X)
The simpliest would be to create a patch that is included *after* the configure-generated .h file. I do not exactly now, in which PHP/Zend specific .h file the configure generated php_config.h one is included, but that would be the place to place the following macro: #if defined(MACOSX) (I do not know the exact macro for detecting osx) # undef WORDS_BIGENDIAN # define WORDS_BIGENDIAN __BIG_ENDIAN__ #endif Just an idea. Or just update to a newer autoconf version that can detect this (I know newer ones do this correctly). But this is not possible for PHP. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Antony Dovgal [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 11:46 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] php5 as universal binary (Mac OS X) Intel Mac is little-endian, PPC Mac is big-endian. Endiannes is detected during configure run, that's why the binary works fine on Intel Mac, but not on PPC. To make it work on both you either need to build separate binaries on PPC and Intel, and then merge them (IIRC that was possible), or you need to patch PHP sources. In my case patching PHP sources was the easiest solution, so I replaced WORDS_BIGENDIAN macro (defined by configure) with __BIG_ENDIAN__ (defined by Mac GCC in compile time). If anyone have any suggestions on how to improve universal binary support so that it would not require patching, I'd gladly listen to them. On 27.07.2007 13:15, Christian Speich wrote: hello, I have asked in the gernal php list and they say I should be ask here: I have an problem with php5 as universal binary on Mac OsX. The universal binary was build on an intel mac and it works good... on an intel mac ;) When a friend it try on an ppc mac he had some problems. For example phpsqliteadmin say this error: Fatal error: Balloc() allocation exceeds list boundary in /Applications/xampp/xamppfiles/phpsqliteadmin/SPSQLite.class.php on line 998 And phpmyadmin loads and loads and loads and loads... BUT my php4 universal binary works perfect on intel and ppc macs... :/ My configure for php5 look like this: PREFIX=/Applications/xampp/xamppfiles SYSCONFDIR=/Applications/xampp/etc export LD_RUN_PATH=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export CFLAGS=-I$PREFIX/include -L$PREFIX/lib -isysroot /Developer/SDKs/MacOSX10.4u.sdk export CPPFLAGS=-I$PREFIX/include export CXXFLAGS=-I$PREFIX/include -L$PREFIX/lib export LDFLAGS=-L$PREFIX/lib -I$PREFIX/include export SOFLAGS=-L$PREFIX/lib CFLAGS=$CFLAGS -arch i386 -arch ppc ./configure --prefix=$PREFIX --program-suffix=-5.2.3 --libdir=$PREFIX/lib/php/php5 --includedir= $PREFIX/include/php/php5 --with-apxs2=$PREFIX/bin/apxs --with-config-file-path=$SYSCONFDIR --with-mysql=$PREFIX --disable-debug --enable-bcmath --enable-calendar --enable-ctype --enable-dbase --enable-discard-path --enable-exif --enable-filepro --enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --with-ttf --enable-magic-quotes --enable-memory-limit --enable-safe-mode --enable-shmop --enable-sigchild --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-wddx --enable-yp --with-ftp --with-ncurses= $PREFIX --with-gdbm=$PREFIX --with-jpeg-dir=$PREFIX --with-png-dir= $PREFIX --with-freetype-dir=$PREFIX --without-xpm --with-zlib=yes --with-zlib-dir=$PREFIX --with-openssl=$PREFIX --with-expat-dir=$PREFIX --enable-xslt=$PREFIX --with-xsl=$PREFIX --with-dom=$PREFIX --with-ldap= $PREFIX --with-gd=$PREFIX --with-mysql-sock=$PREFIX/var/mysql/mysql.sock --with-mcrypt=$PREFIX --with-mhash=$PREFIX --enable-sockets --with-curl=$PREFIX --enable-mbregex --enable-zend-multibyte --with-zip= $PREFIX --enable-exif --with-sqlite --with-libxml-dir=$PREFIX --enable-soap --enable-pcntl --enable-dbx --with-mysqli= $PREFIX/bin/mysql_config --with-bz2=$PREFIX --with-pear= $PREFIX/lib/php/pear --with-mssql=$PREFIX --with-imap-dir=$PREFIX --with-imap=$PREFIX --enable-mbstring=all --with-pgsql=shared,/usr --with-gettext=$PREFIX I don't think thats this are errors from the php-scripts, I think thats an problem with php. I hope you can help me to resolve this problem thanks, kleinweby -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FW: php fastcgi
Where is the propsed patch? I was thinking about a (not SAPI specific the subject indicates) modification to the php-output parts that sends a HTTP status 500 when a fatal error occurs and no output was yet send (SAPI did not start the response). I think there is no need for a configuration setting. A CGI program that crashes on startup creates error 500, a servlet/JSP that does not startup creates error 500,... In principle SAPI should return a FAILURE to the webserver from the handler function and set the status code before. The webserver then generates the default error page. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 6:54 PM To: [EMAIL PROTECTED] Cc: 'internals Mailing List'; 'Stanislav Malyshev'; 'Andrei Nigmatulin' Subject: RE: [PHP-DEV] FW: php fastcgi Configuaratin option make sense, but PHP already has too many configuration options especialliy for error reprting. I would like to avoid new ones. Thanks. Dmitry. -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 8:17 PM To: Dmitry Stogov Cc: 'internals Mailing List'; Stanislav Malyshev; Andrei Nigmatulin Subject: Re: [PHP-DEV] FW: php fastcgi On Wed, June 13, 2007 2:07 am, Dmitry Stogov wrote: Current time most PHP instalations use setting 'display_error=0'. This setting hides errors from user but may send to him just a blank page. The proposed patch sends HTTP 500 response on errors instead of blank pages. The pages that already wrote something are not affectd. Any objections or additions? This sounds perfectly reasonable... But I suspect some users might prefer a 404 or a customizable response of some type... At the risk of incurring the wrath of list members, perhaps yet another php.ini configuration switch could be considered?... I wouldn't hold up the 500 patch for long with this kind of discussion, but it's worth taking a few minutes to consider, I think. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.3RC1 Released
I tried PHP 5.2.3RC1 today and the SunONE webserver using the NSAPI plugin crashed in module startups with a segfault. This happens because rasmus changed tsrm_virtual_cwd.c to use get_request_time instead of time() (see changelog of that file). During module startup the extension browscap tries to open the browscap.ini file and uses the TSRM functions to do that (because TSRM is used in NSAPI). At module startup there is unfortunately no request running so the call to the SAPI routine sapi_nsapi_get_request_time() core dumps because of a missing server_context. I think that should be fixed because it affects all multithreaded webserver SAPIs that supply a get_request_time-function. Here the core dump: #0 0xfc939712 in sapi_nsapi_get_request_time (tsrm_ls=0x0) at /pangaea/install/php-5.2.3RC1/sapi/nsapi/nsapi.c:721 721 return REQ_TIME( ((nsapi_request_context *)SG(server_context))-rq ); (gdb) where #0 0xfc939712 in sapi_nsapi_get_request_time (tsrm_ls=0x0) at /pangaea/install/php-5.2.3RC1/sapi/nsapi/nsapi.c:721 #1 0xfc8782b2 in sapi_get_request_time (tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/main/SAPI.c:990 #2 0xfc86ceb2 in virtual_file_ex (state=0x80476f8, path=0x827d7f0 /pangaea/webserver70/browscap.ini, verify_path=0, use_realpath=1) at /pangaea/install/php-5.2.3RC1/TSRM/tsrm_virtual_cwd.c:522 #3 0xfc86d1b6 in virtual_fopen (path=0x827d7f0 /pangaea/webserver70/browscap.ini, mode=0xfcb4370c r, tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/TSRM/tsrm_virtual_cwd.c:819 #4 0xfc7edaad in zm_startup_browscap (type=1, module_number=12, tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/ext/standard/browscap.c:165 #5 0xfc7e69a2 in zm_startup_basic (type=1, module_number=12, tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/ext/standard/basic_functions.c:4026 #6 0xfc8b7bc6 in zend_startup_module_ex (module=0x8722618, tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/Zend/zend_API.c:1464 #7 0xfc8bece0 in zend_hash_apply (ht=0xfcbc5fe0, apply_func=0xfc8b7b30 zend_startup_module_ex, tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/Zend/zend_hash.c:673 #8 0xfc8b7df4 in zend_startup_modules (tsrm_ls=0x86bd388) at /pangaea/install/php-5.2.3RC1/Zend/zend_API.c:1511 #9 0xfc870804 in php_module_startup (sf=0xfcbb2120, additional_modules=0xfcbb2020, num_additional_modules=1) at /pangaea/install/php-5.2.3RC1/main/main.c:1621 #10 0xfc93973f in php_nsapi_startup (sapi_module=0xfcbb2120) at /pangaea/install/php-5.2.3RC1/sapi/nsapi/nsapi.c:726 #11 0xfc939866 in php5_init (pb=0x8098290, sn=0x0, rq=0x0) at /pangaea/install/php-5.2.3RC1/sapi/nsapi/nsapi.c:859 #12 0xfecde67a in func_exec_str () from /pangaea/webserver70/lib/libns-httpd40.so #13 0xfecde8e6 in INTfunc_exec () from /pangaea/webserver70/lib/libns-httpd40.so #14 0xfecdc45f in __1cSrun_init_functions6Fi_nIPRStatus__ () from /pangaea/webserver70/lib/libns-httpd40.so #15 0xfecdc598 in __1cbCconf_run_late_init_functions6FpnNConfiguration__nIPRStatus__ () from /pangaea/webserver70/lib/libns-httpd40.so #16 0xfed5f237 in __1cJWebServerDRun6F_nIPRStatus__ () from /pangaea/webserver70/lib/libns-httpd40.so #17 0x08050b18 in main () - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany Sent: Friday, May 25, 2007 2:33 AM To: php-dev List Subject: [PHP-DEV] PHP 5.2.3RC1 Released The first release candidate of PHP 5.2.3 is now available for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.3RC1.tar.bz2 (md5sum: 343785b0558f5696c14607d62f084d4c) The release comes a bit sooner then anticipated as it is needed to address a regression introduced by 5.2.2 in relation to RAW_HTTP_POST_DATA handling. I'd like to keep the release cycle as short as possible so we can get this version out ASAP. I'd like to ask everyone to try this release against their code and/or test suits and report any new problems if there are any. If there are no new issues I will move to the final release within 1 week. I'd also like to ask all developers to refrain from making major commits or non-bug-fix commits for the next week to the 5.2 branch. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.3RC1 Released
Does not link: Undefined first referenced symbol in file php_during_module_startup main/.libs/SAPI.o php_during_module_shutdown main/.libs/SAPI.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status gmake: *** [sapi/cli/php] Error 1 - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 9:51 AM To: Uwe Schindler Cc: 'php-dev List' Subject: Re: [PHP-DEV] PHP 5.2.3RC1 Released Rasmus Lerdorf wrote: Uwe Schindler wrote: I tried PHP 5.2.3RC1 today and the SunONE webserver using the NSAPI plugin crashed in module startups with a segfault. This happens because rasmus changed tsrm_virtual_cwd.c to use get_request_time instead of time() (see changelog of that file). During module startup the extension browscap tries to open the browscap.ini file and uses the TSRM functions to do that (because TSRM is used in NSAPI). At module startup there is unfortunately no request running so the call to the SAPI routine sapi_nsapi_get_request_time() core dumps because of a missing server_context. I think that should be fixed because it affects all multithreaded webserver SAPIs that supply a get_request_time-function. Could you try the attached patch please. It should be a time(0) call there in the ternary, of course. Fixed patch attached. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.3RC1 Released
Rasmus Lerdorf wrote: Uwe Schindler wrote: Does not link: Undefined first referenced symbol in file php_during_module_startup main/.libs/SAPI.o php_during_module_shutdown main/.libs/SAPI.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status gmake: *** [sapi/cli/php] Error 1 gah! Who the heck added access functions for the static module globals in main.c that are static themselves? That makes no sense. static int module_startup = 1; static int module_shutdown = 0; ... static int php_during_module_startup() static int php_during_module_shutdown() I had just assumed they were PHP_API functions. Ok, a better approach checking SG(server_context) instead attached. Try that. Works now. No more SEGFAULT. This solution is not the best one, but this was my first idea to fix this, too. It should fix it in other SAPIs, too. Apache for example also uses SG(server_context). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] TSRM changes broke windows compile
An extra syscall on every file open isn't exactly miniscule. It's a syscall not related to any filesystem or I/O so it can't be that bad. And we managed to live with it so far. Edin also just built Windows binaries without problems. Why did it work for him? I have no idea. But it is obvious that it doesn't work in all environments, and it worked before just fine. Anyway, both breaking build _and_ intoducing dependency of TSRM on PHP and both in a minor version _and_ both without discussing it doesn't look like very good idea to me. I would propose: 1. Revert it for 5.2.3 2. Discuss if we want TSRM/Zend be now usable only with PHP 3. Discuss if we really need this patch and if so can we do it without breaking (2) As I was involved today this morning also with startup failures because of this change, I came to the following: It would be perhaps OK to make TSRM dependent on some global PHP functions, but to make it depend on SAPI code that is only for webserver interaction (!) and not related to TSRM (yes SAPI uses TSRM but not the other way round) is not so good. And that only because of a not IO-related syscall! A solution would be to make a function pointer inside TSRM that normally maps to time() or a TSRM-local wrapper of it. This would make TSRM not dependent on PHP. On the PHP part in SAPI startup there could optionally be a redirect of the pointer to SAPI's get_request_time() implementation. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] TSRM changes broke windows compile
It would be perhaps OK to make TSRM dependent on some global PHP functions, but to make it depend on SAPI code that is only for webserver interaction (!) and not related to TSRM (yes SAPI uses TSRM but not the other way round) is not so good. And that only because of a not IO-related syscall! It may not be IO, but on some systems fetching the time is actually quite expensive. And SAPI isn't only for web server interaction. SAPI is a general-purpose abstraction API that sits between PHP and anything PHP talks to. CGI, CLI, and even embedded PHP are all SAPI-driven. There is no way to use PHP without at least a stub SAPI layer. I know, I wanted only to put more pressure on that. A solution would be to make a function pointer inside TSRM that normally maps to time() or a TSRM-local wrapper of it. This would make TSRM not dependent on PHP. On the PHP part in SAPI startup there could optionally be a redirect of the pointer to SAPI's get_request_time() implementation. That could be done, yes. I'm just not sure it is worth the complexity. TSRM is obviously a PHP-specific thing and it is already somewhat SAPI-dependant even without this. The THREAD_T and MUTEX_T definitions change based on the chosen SAPI. This is no longer the case. E.g. when compiling the module for the NSAPI webserver (Sun Java System Webserver) there should be a global define like -DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of that all SAPIs do not have an effect on the thread implementation. When compiling PHP with ZTS you always get an .o file that links to pthreads. This must be the case, because without that it would not be possible to link a CLI PHP in parallel to the webserver specific SAPI. Because of that limitation for example the Sun Webservers on (SJSWS) on AIX crash on startup (there are a lot of bug reports about that, but I cannot help because I have no access to such a system). I only know that SJSWS is implemented on AIX not with POSIX threads. And on Solaris the webservers also crash when you switch to an alternative kernel (do not know the exact name) thread implementation in the webserver. This is because the ifdefs in TSRM.h never apply specific to the SAPI implementation. It doesn't explicitly include SAPI.h because it relies on the side-effect of TSRM.h being included after the SAPI stuff. I don't see an explicit include as really changing things very much. It was just a suggestion. But it should not hard to implement. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] TSRM changes broke windows compile
Hi Rasmus,
This is no longer the case. E.g. when compiling the module for the NSAPI
webserver (Sun Java System Webserver) there should be a global define
like
-DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
that all SAPIs do not have an effect on the thread implementation. When
compiling PHP with ZTS you always get an .o file that links to pthreads.
This must be the case, because without that it would not be possible to
link
a CLI PHP in parallel to the webserver specific SAPI.
That's simply not the case. Look at the nsapi code:
#define NSAPI 1
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include php.h
#include php_variables.h
#include ext/standard/info.h
#include php_ini.h
#include php_globals.h
#include SAPI.h
#include php_main.h
#include php_version.h
#include TSRM.h
#include ext/standard/php_standard.h
#include sys/types.h
#include sys/stat.h
It defines NSAPI before including TSRM.h and in TSRM.h we have:
#elif defined(NSAPI)
# define THREAD_T SYS_THREAD
# define MUTEX_T CRITICAL
Butt his is only for nsapi.c. All other PHP modules and the core itself do
not know anything about NSAPI. This leads to the fact that if the webservers
thread implementation is incompatible to the system default the build .o of
nsapi.c is not compatible to the other .o files.
This happens here:
When compiling TSRM.c with the lines in it:
TSRM_API THREAD_T tsrm_thread_id(void)
{
#ifdef TSRM_WIN32
return GetCurrentThreadId();
#elif defined(GNUPTH)
return pth_self();
#elif defined(PTHREADS)
return pthread_self();
#elif defined(NSAPI)
return systhread_current();
#elif defined(PI3WEB)
return PIThread_getCurrent();
#elif defined(TSRM_ST)
return st_thread_self();
#elif defined(BETHREADS)
return find_thread(NULL);
#endif
}
NSAPI is *not* defined. This is not a problem because the
systhread_current()-NSAPI function internally calls pthread_self() but only
if the webserver runs in pthreads.
On AIX (or was it HP-UX??? I should look into my bug reports) the webserver
runs in another thread implementation. This leads to crashes in the
webserver because PHP uses pthreads (because of TSRM.c) and all the
webserver another one. In the worst case
#define THREAD_T SYS_THREAD
is also incompatible in size and structure and misbehaves between SAPI code
(with define) and PHP (without define).
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Unicode extension in PHP6
What I am thinking is, if unicode_semantics=on, every single time I need to call urlencode (or other binary-only functions) with a variable, I need to typecast it. Well, if this is necessary 100% of the times, why not do this already inside urlencode, and if the string contains bad characters, give the same warning I get on the (binary) typecast on an incompatible string? I am just trying to think logically, I don't know the amout of work something like this would generate. If this is done, ate least 1 25000 lines PHP application will work on PHP6 with 5 line changes. I think this is great marketing for PHP6 migration. Yes, I am sure we can do something intelligent with some of these cases. It's still quite early in the migration and we are likely to revisit many of these functions to make them more flexible. I don't really see why urlencode() shouldn't be smarter about handling Unicode strings. I jst compare urlencode/urldecode with Java that is from its nature using Unicode. http://java.sun.com/javase/6/docs/api/java/net/URLEncoder.html The input parameter is a *String* (which is per definition Unicode in Java). The output is (a ASCII-only) string with the URL-encoded values. The character set for the out put is choosen by an additional parameter (that could be done in PHP, too) or it uses the platform default (in PHP that would be the encoding used to write strings to files or the web output. This default encoding would fully conform to what is currently done when creating web pages. Web Browsers encode the entered values in the encoding the webpage, that contains the form, uses. A php script that generates URLs should act in the same way, so the URLencoded values in an URL should be encoded using te characterst that is used for text output. A special case would be the HTTP/URI standard that states that URLs should encoded always UTF-8 (but ALL browser do not do this for form values). But they do it for encoding path components containing special characters and webservers exspect it in that way when mapping the path component to a local filesystem. So the default encoding when using rawurlencode (which is normally used NOT for forms but more for Pathes, DOIs, URNs,...) should be UTF-8. But I think that would be contraproductive to differentiate between rawurlencode and urlencode. But for the case when a user want to encode a string to a different encoding, he could use an optional second parameter to (raw)urlencode (like in Java). In the case that (raw)urlencode is given a *binary* string the second parameter should be disallowed and a warning or what ever should be raised. A binary string should encode byte-by-byte as before! I think this would make a lot of applications more backwards compatible and code more simplier. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Setting HTTP results code vs. HTTP type
- Update the PHP header() documentation to mention this. I was also
thinking that supporting/documenting header(null, true, 404); or the
like would be nice for people who only want to set the return code and
leave the HTTP type unchanged.
I think this would bet he best approach, to give the PHP a users a
_consistent_ way (consistent through all SAPIs) to set the http response
code without changing protocols.
Your problem only occurs with apache, as apache gives PHP the possibility to
change the HTTP protocol version. Other SAPIs, like my NSAPI one, cannot do
this because the protocol is the servers task and modules are not allowed to
change it in a wrong way.
The problem with setting the response code is:
* Some PHP scripts use header('Status: 301') to set response code. Problem
here: This only works with CGI and Apache. The problem here is in PHP SAPI
code: PHP only checks for ('HTTP/...') header strings and extracts status
code and protocol version from it. The string 'HTTP/..' is never send to the
SAPI. In case of 'Status: ', SAPI sends the header as a _normal_ HTTP header
to the webserver - Apache maps this, CGI also because specs want this.
* Some scripts use header('HTTP/1.0 301 Moved Permanently'). Problem here:
You must supply a HTTP version (this seems to be a problem in Apache), and
you must supply the textual representation (but most/all? SAPIs ignore the
textual representation). So header('HTTP/1.0 301 X') would be OK.
What we need is:
1) a consistent parsing of header() inputs before sending to the underlying
SAPI. This means also parsing for 'Status: XXX' and setting the status code.
The later SAPI then will generate the correct parameters to be sent to the
server (in case of CGI it will regenerate a Status:-header).
2) a function to simply set the status code without changing anything other.
1. supplies such a method with 'Status: 301' if it is correctly implemented.
If nobody is against it I would try to implement a consistent header parsing
for SAPI...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Setting HTTP results code vs. HTTP type
-Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 2:22 AM To: Oliver Block Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Setting HTTP results code vs. HTTP type Oliver Block wrote: Am Dienstag, 1. Mai 2007 01:49 schrieb Rasmus Lerdorf: This came up many times on the Apache lists years ago, and Roy Fielding who wrote that spec repeatedly said it was fine to reply with a 1.1 response to a 1.0 request. Did he give any rationale for his view? Go read the archives. And note that I only said it was fine to respond with a 1.1 reply, that doesn't mean it is fine to send an encoding the client doesn't support. And that's exactly what other web servers also do: I come from Sun One Web Server 6.1 and 7.0), so I can tell what they do: They respond always with HTTP/1.1 but if the request came in with HTTP/1.0 they do not use chunked encoding for the reply and use Connection: close. Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] dropping asp_tags in HEAD
I use ?=...?, too, because is much more readable in templates. On the other hand I would like to disable short-tags without losing this feature! So my +1 for a change here! - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany Sent: Saturday, April 14, 2007 6:02 PM To: Stut Cc: Bart de Boer; [EMAIL PROTECTED]; Tijnema !; [EMAIL PROTECTED]; Chad Daelhousen; Ron Korving Subject: Re: [PHP-DEV] dropping asp_tags in HEAD If you plan to go far and remove the ? tags, so I suggest to include a ?php=$something? into PHP. Best regards, On 4/14/07, Stut [EMAIL PROTECTED] wrote: Bart de Boer wrote: I think ASP tags should go too... Simply because it's not standards compliant and I think it's good if people are forced to make nice standards compliant documents... I'd even go so far as to favor dropping short tags too... ? echo ?xml version=\1.0\ encoding=\UTF-8\ ?\n; ? What a mess!... I agree, but I do like the ?= tag. Personally I would like to see short tags dropped but retain support for ?= as it makes templates a lot easier to read, i.e. ?=$var? against ?php print $var; ?. -Stut -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com São Carlos - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] dropping asp_tags in HEAD
Well, then ? collides also. So the suggestion is to drop everything but script language=php? ;) To be really compliant this should be script type=text/php or some other content-type :) Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.1RC4 Released
Installed RC4 short time ago, works great. I found only a problem in phpinfo(): Registered PHP Streams: zip Registered Stream Socket Transports: tcp Registered Stream Filters: string.rot13 It only displays the FIRST registered PHP stream. Testing with fopen(http://...;) works, so all streams are available. This bug was also in RC3 but I thought it was related to http://bugs.php.net/bug.php?id=40168 and did not start any separate bug report. System is Solaris 9 SPARC, GCC 3.3 - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 1:33 AM To: internals@lists.php.net List Subject: [PHP-DEV] PHP 5.2.1RC4 Released The final release candidate for PHP 5.2.1, RC4 is now available for download. Pending any problems this will be released as 5.2.1 next week, so this is the last chance to identify any critical issues before it is too late. If you have not tried any previous RCs, please do so now. The tar balls can be found at the URLs below and win32 binaries will follow shortly. http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum: f50578276f653b1f523150e3ff987f03) http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum: 361197eb2b21b36e2e20cb132da2cf16) I'd like to ask all developers to refrain from making any (no matter how trivial) commits to the 5.2 branch until 5.2.1 is released, if you feel you have a critical patch, please run it by me first, thanks. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default charset
Hi Graziano,
At 10:42 04.01.2006, you wrote:
I need to set the default charset for my application to UTF-8 instead of
the default one of the webserver that is ISO-8859-1.
I've tried to change the value of default_charset in php.ini and all it's ok,
but I need to set the value only for one application so I've tried to use the
ini_set function in this way:
ini_set('default_charset','utf-8');
The problem is that that the ini_set function seems to be ignored, I don't
have the same effect of changing the php.ini configuration file, with the
ini_set function the default charset of the output is still ISO-8859-1.
create a .htaccess file in the application directory where you use
the php_value command to set this variable. See http://www.php.net/php_value
The problem is that changing the charset in the script is too late
(it is running so it cannot be changed anymore).
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
No NEW problems on Solaris 9, only with latest 5.1 snapshot: * make test still does not work * make install fails because some PEAR components are missing (see mail of Pierre) * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) Uwe At 13:20 14.09.2005, Zeev Suraski wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
At 16:18 14.09.2005, you wrote: On Wed, 14 Sep 2005, Uwe Schindler wrote: * make test still does not work Like..how? I posted this one month ago (other thread). It fails when calling test with an empty expression: [EMAIL PROTECTED]:~/install/php5-200509141230$ gmake test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php5-200509141230$ 4.3 and 5.0 worked in the past. * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) And the garbage is..? checking whether ln -s works... yes checking if compiler supports -R... yes checking for re2c... no configure: warning: You will need re2c 0.98 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for bison... no checking for byacc... no checking for bison version... ./configure: bison: not found AWK=gawk CC=gcc CFLAGS=-g -O2 CONFIGURE_COMMAND= './configure' '--prefix=/pangaea/gnu' '--enable-cli' '--with-nsapi=/pangaea/webserver61' '--with-sybase-ct=/opt/csw' '--with-mysql=/opt/csw/mysql4' '--enable-ftp' '--enable-versioning' '--enable-session' '--enable-trans-sid' '--with-zlib=/opt/csw' '--enable-mbstring=all' '--with-openssl=/opt/csw' '--with-gd' '--with-png-dir=/opt/csw' '--with-jpeg-dir=/opt/csw' '--with-ttf=/opt/csw' '--with-libxml-dir=/opt/csw' '--with-iconv=/opt/csw' '--with-iconv-dir=/opt/csw' '--with-xsl=/opt/csw' '--enable-soap' '--without-sqlite' '--enable-exif' '--with-curl=/opt/csw' '--with-curlwrappers' '--with-pdo-mysql=/opt/csw/mysql4' '--with-xmlrpc' '--without-pdo-sqlite' '--with-pdo-dblib=/opt/csw' CONFIG_SITE=/pangaea/gnu/share/config.site /pangaea/gnu/etc/config.site CPP=gcc -E CYGWIN= ECHO=/usr/ucb/echo EGREP=egrep EXTRA_VERSION=RC2-dev GCC=yes HOME=/pangaea HOSTNAME=pans1 HOSTTYPE=sparc ... and more crap then: with_xsl=/opt/csw with_zlib=/opt/csw x_includes=NONE x_libraries=NONE invalid configure: warning: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 (found: dummy.byacc). checking for flex... lex checking for yywrap in -ll... yes checking lex output file root... lex.yy checking whether yytext is a pointer... no checking for working const... yes checking for flex version... invalid configure: warning: flex versions supported for regeneration of the Zend/PHP parsers: 2.5.4 (found: ). checking whether to force non-PIC code in shared modules... no checking for pthreads_cflags... ^C But configure works. Greetings, Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1RC1 on Solaris
At 21:07 22.08.2005, Wez Furlong wrote: On 8/22/05, Uwe Schindler [EMAIL PROTECTED] wrote: /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php-5.1.0RC1$ (I think, this is the old problem with Solaris' test, that we fall into every time... :) ) Changing a test -e to a test -f fixed this kind of problem for me when I was hacking on the dtrace stuff at oscon. This error is stille there. Should I commit a patch for the makefile to use test -f or has this any implications for other architectures? A second error is in the configure script (which does not crash). When checking for the first time for bison it prints out a lot of garbage (env variables,... about 200 lines) finally saying that bison is missing (which is correct). Should I sent the garbage? - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.1: Does it still require ext/xmlrpc for pear?
At 16:23 28.08.2005, you wrote: 'Replace'? Code written for ext/xmlrpc won't work with ext/xmlrpci. Will ext/xmlrpc be available in PECL, given that it doesn't appear to have an active maintainer? I'm well aware of ext/xmlrpc's limitations, haven't tried the new (but necessary) pecl/xmlrpci yet, and have the tiny issue that a bunch of my scripts will need a complete rewrite if the old extension is simply taken away from PHP 5 up. I suspect I'm far from being alone in that - do we have figures for core extension usage, anyone? How about placing some compatibility functions in ext/xmlrpci or a PEAR package that emulates this using xmlrpci, if it is not too development expensive? This would put everything to libxml2 and everybody would be happy. Why do we need to completely rewrite all this xmlrpc stuff? Because SOAP uses XMLRPC in SOAP envelopes (when encoding is rpc) - why not reuse the soap extension for plain xmlrpc without soap envelopes? - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.1RC1 on Solaris
Hello folks, came back from holidays and started to test RC1 of PHP5.1 on our solaris box, two things: The first: == [EMAIL PROTECTED]:~/install/php-5.1.0RC1$ gmake test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php-5.1.0RC1$ (I think, this is the old problem with Solaris' test, that we fall into every time... :) ) The second: === when someone uses --without-sqlite it should automatically assume also --without-pdo-sqlite Finally: what is the the status of snaps.php.net, which versions get downloaded here at this time? - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany
Re: [PHP-DEV] PHP 4.4 branch
At 19:38 07.06.2005, Derick Rethans wrote: On Mon, 6 Jun 2005, Derick Rethans wrote: If you have any issues that you really want to get fixed in PHP 4.4, please reply to this email (on the internals@ list). If there is nothing, I'd like to start releasing RC1 on Monday. regards, Derick Only one thing: after you reverted my patch (because of my error with the man pages - i'm sorry) the installation of manpages in 4.4 does not work because the variable $(man_PAGES) is not defined in Makefile.frag (it never worked). I also removed the $(bin_src_SCRIPTS) part like in 5.0 and HEAD because the solaris /bin/sh does not like empty lists in for-loops. If there is no problem this time I will apply this patch. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany Index: scripts/Makefile.frag === RCS file: /repository/php-src/scripts/Makefile.frag,v retrieving revision 1.1.2.11.2.3 diff -u -r1.1.2.11.2.3 Makefile.frag --- scripts/Makefile.frag 7 Jun 2005 21:57:13 - 1.1.2.11.2.3 +++ scripts/Makefile.frag 8 Jun 2005 07:59:47 - @@ -21,7 +21,7 @@ config.sub bin_SCRIPTS = phpize php-config -bin_src_SCRIPTS = +man_PAGES = phpize.1 php-config.1 install-build: @echo Installing build environment: $(INSTALL_ROOT)$(phpbuilddir)/ @@ -63,10 +63,6 @@ echo program: $(program_prefix)$$prog$(program_suffix); \ $(INSTALL) -m 755 $(builddir)/$$prog $(INSTALL_ROOT)$(bindir)/$(program_prefix)$$prog$(program_suffix); \ done - @for prog in $(bin_src_SCRIPTS); do \ - echo program: $(program_prefix)$$prog$(program_suffix); \ - $(INSTALL) -m 755 $(top_srcdir)/scripts/$$prog $(INSTALL_ROOT)$(bindir)/$(program_prefix)$$prog$(program_suffix); \ - done @echo Installing man pages: $(INSTALL_ROOT)$(mandir)/man1/ @$(mkinstalldirs) $(INSTALL_ROOT)$(mandir)/man1 @for page in $(man_PAGES); do \ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Linuxtag 2005
Hi all, on which mailinglist is management of Linuxtag 2005? I want to meet the others there, too, because I got free for these days. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard md5.c sha1.c
We can left that out. The flag to search in the include path is available
to all file_* functions in PHP. Make it sense to search in the include path
for example in the exif-functions? But this parameter is available there,
too. So for consistency I added this parameter.
At 16:37 15.04.2005, you wrote:
Hi,
what's the reason for looking in the include path. Usually these
functions are used to verify the MD5/SHA1 hash of a specific file.
Regards,
Andrey
Uwe Schindler wrote:
thetaphiFri Apr 15 10:29:32 2005 EDT
Modified files:
/php-src/ext/standard md5.c sha1.c Log:
use streams api for md5_file and sha1_file. Added parameter
use_include_path similar to other PHP file functions. Documentation
update outstanding
http://cvs.php.net/diff.php/php-src/ext/standard/md5.c?r1=1.36r2=1.37ty=u
Index: php-src/ext/standard/md5.c
diff -u php-src/ext/standard/md5.c:1.36 php-src/ext/standard/md5.c:1.37
--- php-src/ext/standard/md5.c:1.36 Fri Apr 15 05:14:38 2005
+++ php-src/ext/standard/md5.c Fri Apr 15 10:29:32 2005
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: md5.c,v 1.36 2005/04/15 09:14:38 thetaphi Exp $ */
+/* $Id: md5.c,v 1.37 2005/04/15 14:29:32 thetaphi Exp $ */
/* * md5.c - Copyright 1997 Lachlan Roche @@ -24,9 +24,6 @@
*/
#include php.h
-#include sys/types.h
-#include sys/stat.h
-#include fcntl.h
#include md5.h
PHPAPI void make_digest(char *md5str, unsigned char *digest)
@@ -70,51 +67,45 @@
}
/* }}} */
-/* {{{ proto string md5_file(string filename [, bool raw_output])
+/* {{{ proto string md5_file(string filename [, bool raw_output [, bool
use_include_path]])
Calculate the md5 hash of given filename */
PHP_NAMED_FUNCTION(php_if_md5_file)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
+ zend_bool use_include_path = 0;
char md5str[33];
unsigned char buf[1024];
unsigned char digest[16];
PHP_MD5_CTX context;
- int n,fd;
+ int n;
+ php_stream*stream;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|b, arg,
arg_len, raw_output) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|bb,
arg, arg_len, raw_output, use_include_path) == FAILURE) {
return;
}
-
- if (PG(safe_mode) (!php_checkuid(arg, NULL,
CHECKUID_CHECK_FILE_AND_DIR))) {
- RETURN_FALSE;
- }
-
- if (php_check_open_basedir(arg TSRMLS_CC)) {
- RETURN_FALSE;
- }
-
- if ((fd = VCWD_OPEN(arg, O_RDONLY)) == -1) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to
open file);
+
+ stream = php_stream_open_wrapper(arg, rb,
+ (use_include_path ? USE_PATH : 0) | REPORT_ERRORS |
ENFORCE_SAFE_MODE, NULL);
+ if (!stream) {
RETURN_FALSE;
}
PHP_MD5Init(context);
- while ((n = read(fd, buf, sizeof(buf))) 0) {
+ while ((n = php_stream_read(stream, buf, sizeof(buf))) 0) {
PHP_MD5Update(context, buf, n);
}
PHP_MD5Final(digest, context);
+ php_stream_close(stream);
+
if (n0) {
- close(fd);
RETURN_FALSE;
}
- close(fd);
-
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
http://cvs.php.net/diff.php/php-src/ext/standard/sha1.c?r1=1.10r2=1.11ty=u
Index: php-src/ext/standard/sha1.c
diff -u php-src/ext/standard/sha1.c:1.10 php-src/ext/standard/sha1.c:1.11
--- php-src/ext/standard/sha1.c:1.10Fri Apr 15 05:14:38 2005
+++ php-src/ext/standard/sha1.c Fri Apr 15 10:29:32 2005
@@ -16,12 +16,9 @@
+--+
*/
-/* $Id: sha1.c,v 1.10 2005/04/15 09:14:38 thetaphi Exp $ */
+/* $Id: sha1.c,v 1.11 2005/04/15 14:29:32 thetaphi Exp $ */
#include php.h
-#include sys/types.h
-#include sys/stat.h
-#include fcntl.h
/* This code is heavily based on the PHP md5 implementation */ @@
-69,51 +66,46 @@
/* }}} */
-/* {{{ proto string sha1_file(string filename [, bool raw_output])
+
+/* {{{ proto string sha1_file(string filename [, bool raw_output [, bool
use_include_path]])
Calculate the sha1 hash of given filename */
PHP_FUNCTION(sha1_file)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
+ zend_bool use_include_path = 0;
char sha1str[41];
unsigned char buf[1024];
unsigned char digest[20];
PHP_SHA1_CTX context;
- int n, fd;
+ int n;
+ php_stream*stream;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|b, arg,
arg_len, raw_output) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|bb,
arg, arg_len, raw_output, use_include_path) == FAILURE
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard md5.c sha1.c
I can remove this parameter. Without it, the function declaration keeps constant and we could add this patch to PHP_5_0, too. It does not change the user interface but makes C code simplier and adds support for URLs without any cost to it. The original intention to change the md5/sha1 code was to remove stdio and convert to posix io (as done in 4.3 and 5.0) because of the solaris stdio problems. But php_streams is even better. Uwe At 17:08 15.04.2005, you wrote: Uwe Schindler wrote: We can left that out. The flag to search in the include path is available to all file_* functions in PHP. Make it sense to search in the include path for example in the exif-functions? But this parameter is available there, too. So for consistency I added this parameter. At 16:37 15.04.2005, you wrote: Then file_exists() is also incosistent :). Do add additional param to it too. Andrey - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de - http://www.schindlers-software.de eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard md5.c sha1.c
At 18:51 15.04.2005, Sara Golemon wrote: Rather than getting prototype change happy. How about a context parameter for the file:// wrapper since it only applies to plainfiles anyway. (Note: Okay so it applies to plainfile wrappers like compress.gzip:// but that just opens the subordinate resource as a wrapper and winds up at file:// anyway) Keep the flag on functions like fopen() for BC purposes, but don't add it anywhere else, there's no need for it. Parameter removed again. Any complaints to add this patch (lowlevel file io to streams in sha1_file md5_file) to PHP_5_0 (PHP_4_3 ???), too? Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix crash in solaris when fdopen() fails
OK - I found out that the fdopen() code is never called in the PHP environment, so patch is not needed (PHP sets zend_file_handle always to STREAM). But I still want to know for what extensions/functions the casts from posix to stdio are needed- Will casting appear somewhere when the user calls the userlevel-file-functions starting with fopen()?. It is hard work to find out with simple search through CVS. The only position I know is because of popen() etc. in the exec functions which are stdio (posix variants are more complicated), which is the cause for the bug report I mentioned. At 09:40 07.04.2005, Uwe Schindler wrote: I am fixing bug #32614: Problem, on the solaris platform fdopen() can fail even if fd is a correct file descriptor, when fd255 (the well-known solaris stdio problem). The webserver of the user crashes because the return value of fdopen() is not checked for NULL when casting a stream from posix to stdio. After this fd==-1 and fp==NULL == further calls to fread/fwrite with this fp segfault. I committed the patches for PHP but I have no karme for ZendEngine2. Can someone with karma submit this patch? According to this it would be interesting, WHEN some PHP/Zend code tries to cast a POSIX stream to stdio? In which extension/functions? Can this be fixed to only use posix IO? The zend engine itself should be safe since 4.3.3 and since PHP5. Does stream casts apply if a user uses the PHP user functions fopen, fread, fwrite? Since Saschas fix in PHP4 there this does not happen. What about PHP5? I would try to fix this everywhere in the future. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix crash in solaris when fdopen() fails
I am fixing bug #32614: Problem, on the solaris platform fdopen() can fail
even if fd is a correct file descriptor, when fd255 (the well-known
solaris stdio problem). The webserver of the user crashes because the
return value of fdopen() is not checked for NULL when casting a stream from
posix to stdio. After this fd==-1 and fp==NULL == further calls to
fread/fwrite with this fp segfault.
I committed the patches for PHP but I have no karme for ZendEngine2. Can
someone with karma submit this patch?
According to this it would be interesting, WHEN some PHP/Zend code tries to
cast a POSIX stream to stdio? In which extension/functions? Can this be
fixed to only use posix IO? The zend engine itself should be safe since
4.3.3 and since PHP5.
Does stream casts apply if a user uses the PHP user functions fopen, fread,
fwrite? Since Saschas fix in PHP4 there this does not happen. What about PHP5?
I would try to fix this everywhere in the future.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
Index: Zend/zend_stream.c
===
RCS file: /repository/ZendEngine2/zend_stream.c,v
retrieving revision 1.10
diff -u -r1.10 zend_stream.c
--- Zend/zend_stream.c 13 Mar 2005 17:48:45 - 1.10
+++ Zend/zend_stream.c 7 Apr 2005 07:29:54 -
@@ -60,6 +60,9 @@
case ZEND_HANDLE_FD:
file_handle-handle.fp = fdopen(file_handle-handle.fd,
rb);
+ if (file_handle-handle.fp == NULL) {
+ return FAILURE;
+ }
file_handle-type = ZEND_HANDLE_FP;
break;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.0.4 won't compile as per your instructions
PHP 5 has a new Unix-Like build system. The DSP files are not longer maintained. To compile you have to configure first and then compile at the command line. You need Windows Scripting (for JavaScript configure script) and a Microsoft Compiler to start the configure.js script and then nmake. At 00:12 06.04.2005, Jeff Beidler wrote: Hello, I have been trying to compile PHP 5.0.4 (downloaded fresh today) and have been following your instructions at http://www.php.net/manual/en/install.windows.building.php to the letter. I always end up with the same thing when trying to compile... 3 errors and a bunch of warnings. I have attached the output from the compiler (Visual C++ 6.0) for reference. One other thing of note (I don't know whether this relates to my problem or not) is that when opening the workspace, VC++ also wants the path to php5activescript.dsp, which is nowhere to be found in the php-5.0.4 tree. Would you please be so kind as to take a look at the errors I'm getting and steer me in the right direction? Many thanks, Jeff Beidler [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de - http://www.schindlers-software.de eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #32424
Jani assigned bug 32424 to me: http://bugs.php.net/bug.php?id=32424edit=1 I think I have the solution for that problem, but I do not know how to fix it because it is not NSAPI specific and I do not know exactly whats going on in output.c. The problem: In a normal PHP request with headers to the user it works in that way (sapi functions called): * sapi_nsapi_header_handler() is called for each header * sapi_nsapi_send_headers() is called when output to client begins and headers should be sent (NSAPI does nothing with headers here because the webserver itsself send the header set before - but NSAPI calls the function in webserver api to start output to client and sets the status code) * sapi_nsapi_ub_write() is called to write output When output buffers are used and no output is sent to browser so far - calling ob_flush flushes its internal buffers. But in all SAPI code this flush function is always called *before* php_header() (in my nsapi_virtual code, too) what calls sapi_nsapi_send_headers() - so the webserver api to start the output is not called - iPlanet sends nothing to the client. The problem with nsapi is the call to the webserver api to start output, other servers like apache do not have such problems because they do not start output explicitely: There are two solutions: a) Check in sapi_nsapi_ub_write() if output was initialized before (could be done by me - but its only bad hack) b) Fix the SAPI to correctly keep the order of SAPI calls when flushing buffers etc. What do you mean? - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PHP_IMAP New Function imap_partialbody to fetch chunks of a MIME attachment
How about the idea to make a function like imap_getbodystream(...) that
returns a PHP stream that can be read with fread() etc. and then closed by
fclose()?. This could be done by using Wez's PHP stream wrappers in PHP5
(even in PHP4.3).
Uwe
At 00:47 15.08.2004, you wrote:
This new function is intended to add chunking capability to fetching
attachments from an email using the IMAP library. Currently the attachment
fetch is done with imap_fetchbody , and is placed entirely in memory, ergo
- if the attachment is larger than the available memory it will fail.
This function has the following prototype - string
imap_partialbody(resource stream_id, int msg_no, int section, int start,
int len [, int options])
It's exactly like imap_fetchbody, except it adds the parameters start
(for the start position offset) and len (for the number of bytes to
retrieve). I've also made sure that the correct checks for message number
are in the code (as per the recent change to imap_fetchbody).
It uses the function mail_partial_body in the C Client, which doesn't
appear in any of the very dated documentation, but I found a few postings
by Mark Crispin explaining how to use it, and it's also been used in pine.
One complication is that it uses a callback to populate the buffer, but I
found some hints on how to use a spare pointer element in the IMAP
stream structure from a post by him in one of the online IMAP forums here
- http://www.webservertalk.com/message299504.html
Obviously the benefit is that a new attachment retrieval could be
implemented in webmail such as IMP that doesn't require the memlimit on
the server to be set to some absurd value, and would be less likely bring
the server to its knees when some idiot mails a 50M video to a group of
his friends. Note however c-client is still greedy about memory for its
cache (theres nothing that can be done about that) - but this doesn't
figure in the PHP memlimit.
A snippet of some resulting PHP using the function (struct is the return
from imap_fetchstructure - note I haven't put anything in to decode the
structure or errorcheck the return for brevity). CHUNKSIZE is how much to
fetch at a time (100K works quite well)
$size=$struct-parts[$partindex]-bytes;
$fp=fopen($attachfile,w);
for ($i=0;$i$size;$i+=CHUNKSIZE)
{
$len = (($size-$i)CHUNKSIZE) ? $size-$i:CHUNKSIZE;
$pbody = imap_partialbody($imap,$msgno,$partno,$i,$len);
fwrite($fp,$pbody);
}
You will find this code works fine on a large attachment, and doesn't blow
the memlimit when its set to the default of 8M.
The next problem of course is that php/php_imap doesn't have a streamed
Base64 decoder - though I've used a simple command line one quite effectively.
I'm guessing if this is of interest, it will be of most interest to the
HORDE/IMP team?
Crispin Olson
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PHP_IMAP New Function imap_partialbody to fetch chunks of a MIME attachment
This would be also interesting: For decoding base64 binarys you could use the string.base64 stream filter then (PHP5)! :) Uwe At 18:50 15.08.2004, Crispin Olson wrote: Uwe Schindler wrote: How about the idea to make a function like imap_getbodystream(...) that returns a PHP stream that can be read with fread() etc. and then closed by fclose()?. This could be done by using Wez's PHP stream wrappers in PHP5 (even in PHP4.3). Uwe Uwe, Not a bad idea, and I had thought of it too. Surely I need to be looking at the Streams API for extension authors though, rather than the wrapper functions if I want to create and maintain my own stream? At this point I've kept it simple, because for the most part, php_imap is a simple wrapper layer onto the UW c-client, and that is also true for this function. Crispin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] snaps.php.net - STABLE snapshot for PHP5
Looking on snaps.php.net I cannot find a PHP5-STABLE release, only latest HEAD and PHP4-STABLE. I think the branch PHP_5_0 should also be available via snaps.php.net - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Spammer on Bugs page
There is some spammer on the bugs page who updates all bugs and adds a new comment to every bug with a URL to a porn page. What can we do? My mailbox gets fuller and fuller... - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Changing php.ini values in SunONE webserver question
According to bug #28878 please read the last comment:
http://bugs.php.net/bug.php?id=28878
The user wants to set doc_root or open_basedir from the obj.conf of his
webserver. He cannot do this because the NSAPI plugin changes only
PHP_INI_USER values:
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_USER, PHP_INI_STAGE_RUNTIME)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
NSAPI is multithreaded so changing of SYSTEM values reflects to other
threads or not? In my thoughts at PHP_INI_STAGE_RUNTIME you can only change
PHP_INI_USER variables or is that wrong?
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing php.ini values in SunONE webserver question
Its no problem... :) Works correct. Changed.
At 11:58 23.06.2004, Uwe Schindler wrote:
According to bug #28878 please read the last comment:
http://bugs.php.net/bug.php?id=28878
The user wants to set doc_root or open_basedir from the obj.conf of his
webserver. He cannot do this because the NSAPI plugin changes only
PHP_INI_USER values:
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_USER, PHP_INI_STAGE_RUNTIME)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
NSAPI is multithreaded so changing of SYSTEM values reflects to other
threads or not? In my thoughts at PHP_INI_STAGE_RUNTIME you can only
change PHP_INI_USER variables or is that wrong?
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP and Apache2
Due to a lot of emails and bug reports from SunONE webserver users, the apache2 multithreading message should also be marked as important for *ALL* multithreaded webservers. With some modifications it could be used for all multithreaded environments not only Apache2. We could link this faq message from all multithreaded webserver install sections. Especially for SunONE webservers there is also the possibility to use FastCGI since version 6.1 (the Zend module is bundled there, but without any documentation and click'n'play availability in the admin server) - so users want to use ext/GD... can use this with some speed drawback (the NSAPI module is *very* fast compared to FastCGI - because multithreaded) and missing features (no virtual() function, no apache-like php_value options). Uwe At 11:56 16.06.2004, Jan Lehnardt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 16 Jun 2004, at 11:35, Joseph Lee wrote: I have seem this questions been asked many times in a few mail list. Someone should post this reply into a FAQ page or the Manual in www.php.net I am about to commit this to the installation chapter of the manual. Jan - -- GPG Key: BB96 56B0 Q: Thank Jan? - A: http://geschenke.an.dasmoped.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFA0Bk17KW8t7uWVrARAmfUAJ9mIGqzR0WOe90AHNB/p00HMUbn5QCeNC8a I6o3NcztxMST3cWRpZJvac4= =dz2E -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sybase-CT bug #28354
works. At 22:28 21.05.2004, Timm Friebe wrote: On Fri, 2004-05-21 at 21:59, Timm Friebe wrote: On Fri, 2004-05-21 at 21:19, Daniel Convissor wrote: [...] It would be appreciated if we can get Sybase working. Right now it causes PHP to crash. http://bugs.php.net/bug.php?id=28354 I'm able to reproduce - I just added a testcase and will have a look into it. In the meantime, don't use sybase_free_result($result); Should be fixed (both PHP4 and PHP5 branches). - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] primitive load order deps for unix build system
i can do Solaris (and MacOSX - but thats GNU) later this evening. At 12:41 21.05.2004, Andi Gutmans wrote: If people can step up and test it on a few of the non-GNU systems I mentioned (and possibly others) then I wouldn't object to commiting it. Any volunteers? Andi At 11:37 AM 5/21/2004 +0100, Wez Furlong wrote: For people that want to build modular extensions (such as PDO) as static, it is. My preference for that is to require it to be built as shared (via PECL), so I'm not going to push the patch. If there are people out there with those other systems, it would be nice if they could test the patch before next week so that we can have a better evaluation of it. Despite PDO being a PECL-only extension by design, a number of people are already attempting (and failing!) to run it as static, because the module init order is undefined. --Wez. -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: 21 May 2004 11:27 To: Wez Furlong; [EMAIL PROTECTED] Cc: 'Sascha Schumann' Subject: RE: [PHP-DEV] [PATCH] primitive load order deps for unix build system Well the main problem is that awk might behave differently on all sorts of non-GNU systems (Sun, AIX, HP etc.). Is it important to include this in 5.0? At 09:22 AM 5/21/2004 +0100, Wez Furlong wrote: Only linux so far. I can check it out on fbsd and solaris a little later. --Wez. -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: 21 May 2004 05:47 To: Wez Furlong; [EMAIL PROTECTED] Cc: 'Sascha Schumann' Subject: Re: [PHP-DEV] [PATCH] primitive load order deps for unix build system How many platforms did you check this one? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3.6RC2 Released
On the qa.php.net page are the links to the source incorrect (still RC1). At 19:05 05.04.2004, Ilia Alshanetsky wrote: A quick update of the RC1 release. This release fixes the INF/NAN bug that was not fully resolved in RC1 and should allow the compilation of the GD extension against GD library 1.X. If no other problems creep up, RC2 will be released as 4.3.6 final on Thursday, so please test it. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cleaning up the browscap mess
But we can link it like tidy/soap into PHP5... I think a good fix would be Jays changes. +1 for commiting. I told him 3/4 of a year ago to put $ and ^ around the regexes (I tested that on my server) and so I think he can commit it. Uwe At 09:16 01.03.2004, you wrote: On Sun, 29 Feb 2004, Rasmus Lerdorf wrote: I would suggest as a first step to pull it out of ext/standard and create a pecl extension for it and second to go through and figure out if we can continue to use the ini parser for this, which I am guessing we can't, so the third task is likely to write a new parser for it. If you make it a pecl extension it won't be available to a lot of people, so I think it's not a good idea to do so. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling 2 SAPIs
At 17:40 27.01.2004, you wrote: On Tue, 27 Jan 2004, Jani Taskinen wrote: Here's what I came up with: http://www.php.net/~jani/patches/multi_sapi_build.patch With the patch applied, I'm now able to build at least apache, cli, cgi and embed SAPIs on one run. # ./configure --disable-all --with-apxs --enable-embed (CLI and CGI are build by default..) I build them using static 'core' lib as I dislike the idea of having to install and maintain several libs. :) But if someone insists, it's possible to build one shared lib too..I actually tested with that first. :) Does your patch just build multiple SAPIs as separate shared libs or does it make one shared lib that has multiple SAPIs in it? The latter is what I want. The best (ideal) result would be to have one libphp[45].so that contains the core. The SAPIs should link against it, so we'd have libphpembed.so, libphpapache.so, etc. Can this be done? Would be great. The only thing is: We must compile all SAPIs with ZTS enabled... But thats the same on windows. - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming files
NSAPI is still PHP5-ready (Windows, too; when used with the new build system of Wez). Webserver-called function names are php5_execute, php5_init, php5_auth_trans At 10:33 31.12.2003, you wrote: Any reason not to rename files under sapi/ from php4 to php5? Are there any special things to look out for? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
On my solaris box the fix does it. I tested it by hammering the same PHP script using get_browser() with and without patch. Without patch it gets this error. With not and script works :) The big problem with this bug is that when the error happens the first time (3 threads using get_browser()), the thread which produces the error does not reset the recursion counter (because of the error) and after finishing all threads it is left at 1. When then 2 more threads use get_browser() at the same time the second one gets the error and at the end the counter is left at 2. And then all further calls fail... In my special case today when the error occured it was: 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 1985 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 1985 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 1985 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 150 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 150 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 168.221.143.68 www.pangaea.de - [03/Dec/2003:17:10:09 +0100] GET / HTTP/1.1 200 150 http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=pangaea; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) 6 threads accessed the get_browser() at the same time - 3 of them failed (content-length=150... and visible in error log), counter left at 3 - from this time on get_browser failed to work. I think I should apply the patch to 4.3 and 5 (same problem there) and close the bug. Uwe At 19:20 03.12.2003, Jay Smith wrote: Uwe Schindler wrote: One solution (attached is the patch, if nobody has someone against it I will apply it): I switch off the recursion protection for the browscap hash in zend_hash_init_ex because this hash has no recursive things in it and is not modified after it is created. Uwe That will probably do it. I'm going to try and reproduce this with and without the patch today on our Solaris box and I'll see what I get. I've been swamped recently and haven't been able to give this a good look. (The browscap extension really needs to be gutted, but at least it works, for the most part...) Going to go give this a try now... J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany
[PHP-DEV] browscap and nesting level too deep (bug #25916)
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading webserver).
And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define
HASH_PROTECT_RECURSION(ht)
\
if ((ht)-bApplyProtection)
{
\
if ((ht)-nApplyCount++ = 3)
{
\
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
}
\
}
The browser hashtable is a global variable in browscap.c and can be used by
more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and third
thread tries to do that you will get the error, because (ht)-nApplyCount++
raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
One solution (attached is the patch, if nobody has someone against it I
will apply it):
I switch off the recursion protection for the browscap hash in
zend_hash_init_ex because this hash has no recursive things in it and is
not modified after it is created.
Uwe
At 18:06 03.12.2003, Uwe Schindler wrote:
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading
webserver). And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define HASH_PROTECT_RECURSION(ht) \
if ((ht)-bApplyProtection) { \
if ((ht)-nApplyCount++ = 3) { \
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
} \
}
The browser hashtable is a global variable in browscap.c and can be used
by more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and
third thread tries to do that you will get the error, because
(ht)-nApplyCount++ raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
Index: ext/standard/browscap.c
===
RCS file: /repository/php-src/ext/standard/browscap.c,v
retrieving revision 1.60.2.15
diff -u -r1.60.2.15 browscap.c
--- ext/standard/browscap.c 13 Aug 2003 23:39:03 - 1.60.2.15
+++ ext/standard/browscap.c 3 Dec 2003 17:15:01 -
@@ -149,7 +149,7 @@
zend_file_handle fh;
memset(fh, 0, sizeof(fh));
- if (zend_hash_init(browser_hash, 0, NULL, (dtor_func_t)
browscap_entry_dtor, 1)==FAILURE) {
+ if (zend_hash_init_ex(browser_hash, 0, NULL, (dtor_func_t)
browscap_entry_dtor, 1, 0)==FAILURE) {
return FAILURE;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] sapi apache2 uninitialized content-length value
all other sapi modules do it in the same way... At 15:31 20.11.2003, Ilia Alshanetsky wrote: Why not simply do SG(request_info).content_length = 0; ? Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC1
Yes the SAPI codes are changed (php5_execute was my example from NSAPI SAPI). But the filenames in the win32 distrib are still php4_xxx.dll (see snapshot compile log). At 21:49 12.11.2003, you wrote: Marcus Boerger wrote: I installed php5 from ./makerpm today and yes i needed to LoadModule mod_php5 php5_apache.dll (if i were on windows) Hello Marcus, Well, that's what I though. IIRC, the last time I tried PHP5 under Windows, the Apache SAPI code was changed. I was uncertain what Uwe meant about the php5_execute. Was he refering to the LoadModule directive under Apache? Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 RC1
How about function names (in my SAPI module I changed everything from for example php4_execute to php5_execute for NSAPI). How about Apache and the others? Should be there some in-code fixes, too? At 16:49 12.11.2003, Olivier Hill wrote: Uwe Schindler wrote: One important thing before RC1 is to fix the libraray filenames on Windows to be php5.dll. How is the status about that? I'll do the diff file next Saturday. But we will need to rename some files in case a php4... name doesn't sound right. Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
