Re: [PHP-DEV] phar & apc
Hello steve, why don't you give it a try: http://de.php.net/phar http://pecl.php.net/package/phar marcus Monday, May 7, 2007, 4:55:10 AM, you wrote: > Before reading the thread on the idea of a PHP 5.3 branch, I had never > heard of phar, so please excuse my neophyte questions, but I couldn't > find a reference with the information. On a single website application > environment (as opposed to a shared host type of thing), what are the > performance characteristics of using a phar file to replace a largish > collection of php files? > Does the performance improve or not? does a fast-cgi based > installation make a difference? > Are stat calls for included files short-circuited since it is all > really one file? Does this improve things in windows where file calls > seem so damn slow? Linux? > Most important, how does it work with APC? > thank you for any answers or references to points of study on the web. > -s Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 7:07:09 AM, you wrote: >> they most likely don't, it is designed for deployment and for running >> includes directly. > What do you mean "directly"? Do you mean this is designed for running > application only specifically crafted to run inside phar and would break > some or most of the existing applications not designed specifically for > it? Then even less reason to recommend it as a way to deploy real > applications. It means you can run a phar file. How is that so hard to understand. See the docs: http://php.net/phar >> pear install phar - or - pecl install phar - done >> oh wait the point is that pecl install doesn't work or is in 99% no option > And what is "pear install"? I don't have such command in my Windows by > default. Neither I have it on my Linux. I would have to install PEAR for > that, right? Even only to know what's inside. Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. >> slow? bigger? overhead? > Meaning, of no practical use nobody would package their real-world apps > this way. Then I guess it's not really an option? As said you can try stuff in a phar and then extract it. And lemme think, a war or jar or whatever crap doesn't make java faster either. But hey it would be a nice trick to turn PHP evenmore into Java so you should promote it. >> Interesting and not maintained for the most. Sometimes working on one or >> the other very specific php version only. And often even without >> documentation. > This is as I see for very specific applications too, and the manual says > there's no currently stable version of phar. Strange, pecl lists three stable versions since end of march: http://pecl.php.net/package/phar And phar has been stable since end of last year. We only decided to not mark it stable to be able to rename a few things. > My opinion I see > is that it is not right to recommend it as preferred way to > deploy PHP applications. I know there are many people that it suits > their needs - but those people as I understand have to keep in mind they > work for phar anyway, so they might as well install one more extension. Once again, that is in most cases no option at all. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
It means you can run a phar file. How is that so hard to understand. It is not hard to understand. What seems to be hard to understand is that the scenario you describe is by no way the only scenario PHP files run in. Not all applications are single entry point and of those that are, not all applications are suitable to work in non-filesystem environment. Thus using phar in applications not specifically designed for it and in environments which presume files are in filesystem might prove harder than some think. a war or jar or whatever crap doesn't make java faster either. But hey it would be a nice trick to turn PHP evenmore into Java so you should promote it. If it was meant as some kind of a jab I'm afraid it was lost on me, I don't understand how it is relevant to anything, sorry. :) Strange, pecl lists three stable versions since end of march: http://pecl.php.net/package/phar I guess you should fix the manual then :) Once again, that is in most cases no option at all. How it's no option in most cases? And while we are at it, what is the "most cases" anyway? Is that most PHP deployments including millions of hosting clones all alike or most people supposed to use packaged applications (as opposed to writing own PHP scripts) or most people running complex production environments (as opposed to just playing with some private site) or most of what? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
phar is a good way of deploying PHP code, as PEAR proves. As a cautious developer however, I am reluctant to using optional features that might not be available on my client's installation. And for regular users of PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Andi Gutmans wrote: I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. It seems to me that there are even more people around with their own agendas today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for me, so my next step WOULD be PHP6. For those of us who have already 'dropped' register_globals and magic_quotes in our code, forcing people who have not yet had time to make the move seems a little heavy handed. PHP6 will need a major porting exercise, so keep it until then. As for phar? It sounds a little like PDO. No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Proper discussion and development of elements that are planned to become main stream would be nice, and not the apparently current method of 'I'm doing this in the next release because I want it!' Do we need phar? Is it fully operational on all platforms? How will the currently registered dependencies be addressed? IF it goes into the main distribution presumably the installers are going to be extended to support it's server requirements. Is that appropriate 'mid cycle'? It WOULD be nice to spend some time inside the PHP code base, but at present all spare time seems to be spent monitoring and testing all the changes to the releases and always playing catch up. PHP6 is the next release - PHP5 should now be tied down and put on the same basis as PHP4 before we end up with even more private initiatives creating even more mayhem :( If people want these changes why aren't they working to get PHP6 out? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Unless your clients immediately upgrade to php 5.3 this is the case anyway for some time (probably measured in years). Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. If it's the installer question you could do it in a number of other ways, but phar way is OK too. It would be one thing to use phar-like format as a packaging format used as base for installers (akin to .msi, .rpm, etc) - and as I understand, it is achievable even without having phar extension with the same success (performance is not really a thing for installer). However, running live app from inside phar is entirely different thing. IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. That's exactly what I am saying - that in my opinion such format is not the best thing PHP software developers could (or should) rely on in many scenarios. Putting something in PHP source is a form of endorsement, and I think it should be carefully considered if it's ready for all scenarios before we do that. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stefan Priebsch wrote: phar is a good way of deploying PHP code, as PEAR proves. As a cautious developer however, I am reluctant to using optional features that might not be available on my client's installation. And for regular users of PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. And given the problem getting hosts to ADD PECL extensions, you expect that they will allow a third party application to install things on their locked down machines. I think the first problem is how does it integrate with hosting environments and will those hosts allow it to run? IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 10:04:16 AM, you wrote: >> PHP-based software, installing a PECL extension is not an option. If I >> cannot be sure that phar works on my client's system, I cannot use it to >> deploy software. > Unless your clients immediately upgrade to php 5.3 this is the case > anyway for some time (probably measured in years). I guess we immediately stop unicode development then. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev schrieb: > Unless your clients immediately upgrade to php 5.3 this is the case > anyway for some time (probably measured in years). Sure. But since PHP4 support is discontinued by the end of this year, people will have to upgrade to 5.x (or 6) anyway. That would put phar support in the broad field maybe by mid-year 2008. > for installer). However, running live app from inside phar is entirely > different thing. I fully agree to that. I (currently) see phar as a means of deploying PHP code. But when people start running PHP apps from a phar, I am sure that soon some "caching" mechanism will appear that would just extract the files from the phar to the file system for quicker access - which again would make phar a great tool for deploying PHP code. And, if APC becomes more wide-spread in the future, I guess it does not really matter wether the code is read from filesystem of phar for the first time, since subsequently the pre-compiled code would be read from the cache anyway. Thus, I see no serious performance impact even if you run software from phar, at least when using a bytecode cache. > That's exactly what I am saying - that in my opinion such format is not > the best thing PHP software developers could (or should) rely on in many > scenarios. Putting something in PHP source is a form of endorsement, and > I think it should be carefully considered if it's ready for all > scenarios before we do that. Then, for installation, what other format would you suggest? I think one advantage of phar is that it is backed by PEAR tools that one can expect every PHP developer to have on his system. It would be a good time now to provide some kind of de-facto-standard for deployment of PHP code, and phar is the best candidate I know for this. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi Stefan, On 5/7/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote: Stanislav Malyshev schrieb: > Unless your clients immediately upgrade to php 5.3 this is the case > anyway for some time (probably measured in years). Sure. But since PHP4 support is discontinued by the end of this year, people will have to upgrade to 5.x (or 6) anyway. That would put phar support in the broad field maybe by mid-year 2008. When have we announce that PHP4 support will end by the end of this year? Secondly, expecting than a non existent 5.3 will be the widely used php release in one year sounds wrong to me :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
On Sun, 6 May 2007, Unknown W. Brackets wrote: > Sorry, I apologize. Although you were curt I should not have been so in > reply. > > I used to manage development of a reasonably popular open source project, and > if one of our developers had ever said something like that, it would have > greatly annoyed me. You never really lose that. > > Although I still think you were somewhat rude, I should not have called you on > it as such, which was rude of me. I am sorry. It's not worse than not using a real name to post with Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (631 total including feature requests) ===[*Directory/Filesystem functions] 40661 Open cwd is reset when shutdown handler runs ===[*Programming Data Structures]= 40496 Assigned Test bug35239.phpt still fails ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 38915 Open mod_php: system() (and similar) don't cleanup opened handles of Apache ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP 5.1) 39764 Suspended array_key_exists inconsistent behavior ===[CGI related]== 38476 Open PATH_INFO, ORIG_PATH_INFO, and PHP_SELF not set in Lighttpd1.4.11/PHP4.4.3 ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) 39681 Open this assignment outside class breaks static function call (PHP4 only) ===[COM related]== 37899 Assigned [PATCH] php_char_to _OLECHAR copies junk bytes ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between "zlib.output_compression" and "ob_gzhandler" 37009 Open I got wrong letter Å and å ! 37901 Verified Unable to find the wrapper "file" 38965 Assigned mssql_connect doesn't use TCP 1433 for external SQL Server 39874 Open gztell returns incorrect file pointer number 39894 Open IniFilePath and PHPRC 40586 Open _ENV vars get espcaped when magic_quotes_gpc is on ===[EXIF related]= 39617 Assigned Erroneously uses the GPS version tag to determine byte order of GPS fields ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effecti
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine schrieb: > And given the problem getting hosts to ADD PECL extensions, you expect > that they will allow a third party application to install things on > their locked down machines. I think the first problem is how does it > integrate with hosting environments and will those hosts allow it to run? Hmmm ... isn't the essence of PHP webspace to be able to put PHP scripts/applications there to run them? phar could make the installation of PHP scripts and applications easier as compared to uploading an archive, unzipping it, possibly fixing access rights manually. Any yes, they will allow it to run because it's no different from allowing PHP scripts to run. As a matter of fact, .phar cannot do anything that .php cannot do, but it's just one file which makes it way easier to handler for end-users. Kind regards Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (42 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers 27372 Verified parse error loading browscap.ini at apache startup (new parser required) ===[Arrays related]=== 35277 Suspended incorrect recursion detection ===[Class/Object related]= 33595 Assigned recursive references leak memory ===[Compile Failure]== 34089 Open Configure fails build test for libxml2 ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type "TIMESTAMP(0) WITH LOCAL TIME ZONE" 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument->createAttribute[NS] can't set value 37546 Open DOMDocumentFragment->appendXML namespace support 37796 Open t_is_not_identical for <> ? 37814 Open Php shoul have class friends 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 40713 Open set_magic_quotes_runtime(0) causes Fatal Error 41019 Assigned auto update feature for FastCGI for IIS 41119 Open range() function behavior different on PHP6 and PHP5 ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket ===[Program Execution] 39992 Open proc_terminate() leaves children of child running ===[Scripting Engine problem]= 29687 Open By-reference passed value inside foreach() is no longer working 33487 Assigned Memory allocated for objects created in object methods is not released 39216 Assigned call_user_func and friends don't accept array($this, "func") callback anymore ===[Session related]== 32330 Open session_destroy, "Failed to initialize storage module", custom session handler ===[SimpleXML related] 37076 Assigned SimpleXML ignores .= ===[Unknown/Other Function]=== 39710 Open getprotobyname is not thread-safe ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() Assigned bugs: (reminders sent) dmitry 33595: recursive references leak memory dmitry 41019: auto update feature for FastCGI for IIS dmitry 33487: Memory allocated for objects created in object methods is not released wez 27792: Functions fail on large files (filesize,is_file,is_dir) wez 39171: pdo_mysql configure script sets empty default socket pajoye 34670: imageTTFText for Indian scripts (Devanagari) kalowsky39756: Crashes in fetching resultsets with LONG ASCII columns from MaxDB helly 39216: call_user_func and friends don't accept array($this, "func") callback a
Re: [PHP-DEV] [RFC] Starting 5.3
I fully agree to that. I (currently) see phar as a means of deploying PHP code. But when people start running PHP apps from a phar, I am sure Then you don't need any extension - install should run without it quite well. And, if APC becomes more wide-spread in the future, I guess it does not really matter wether the code is read from filesystem of phar for the It does. For starters, if you put whole multi-megabyte app in one file, you'd have to either load them all and waste a lot of memory or make bytecode caches implement pseudo-filesystem layer on top of it to do it efficiently. And then there are applications that actually use paths and __FILE__ and whatnot. the cache anyway. Thus, I see no serious performance impact even if you run software from phar, at least when using a bytecode cache. Besides performance impact, there's manageability impact. Think of how easy is to work with compiled code as opposed to dynamic language code. Then, for installation, what other format would you suggest? For installation - format compatible with existing tools (as most of the vendors already do). For runtime - I don't think running PHP out of the single huge file is a very good idea whatever the format is. I think one advantage of phar is that it is backed by PEAR tools that I think it's a disadvantage. With all due respect to the PEAR team and the tools, nobody in the world but PEAR team knows what this format is, and there's tens of years of tools to work with other formats, supported by all OSes and languages in existence. I know it works well in all ten use cases that was considered, but once we recommend it to the wide world, there would be thousands of cases it doesn't work. Unix was built on the principle of interoperability, and inventing private formats not supported by anything violates this principle. one can expect every PHP developer to have on his system. It would be a good time now to provide some kind of de-facto-standard for deployment of PHP code, and phar is the best candidate I know for this. I'd say the only one - and I don't think making decision about standard from this position - "we never though of anything better and it just grew as it is so we make it standard" is a good approach. It works for the thing is was built for - distributing PEAR files - but when we talking about PHP-wide policy I don't think we should recommend people running their applications out of phar files. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files
Hi,
I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
calculation of a file uploaded via the HTTP POST method. Being
not uncommon for applications to require some digest of a freshly
uploaded file, doing the math directly in the buffer where the file is
being read can save some time.
A similar patch was submitted in August 2004 and raised some interest,
but never got merged.
Digest calculation is triggered by setting the special input fields
COMPUTE_MD5 and/or COMPUTE_SHA1 to a non-zero value:
(note that these assignments must precede the
field, as in the MAX_FILE_SIZE case.)
The result is found in the special variables
$_FILES[userfile]["md5"] and $_FILES[userfile]["sha1"].
These variables are only defined upon request of the corresponding
digest.
The patch was produced against the php6 CVS version of rfc1867.c
(1.190).
Cheers,
David
--
David Santinoli
Tieffe Sistemi S.r.l. viale Piceno 21, Milano
www.tieffesistemi.com tel. +39 02 45490882
--- main/rfc1867.c 2007-05-05 11:36:25.0 +0200
+++ main/rfc1867.c.new 2007-05-05 01:04:28.0 +0200
@@ -32,6 +32,8 @@
#include "php_globals.h"
#include "php_variables.h"
#include "rfc1867.h"
+#include "ext/standard/md5.h"
+#include "ext/standard/sha1.h"
#define DEBUG_FILE_UPLOAD ZEND_DEBUG
@@ -1011,8 +1013,18 @@
U_STRING_DECL(name_key, "name", 4);
U_STRING_DECL(filename_key, "filename", 8);
U_STRING_DECL(maxfilesize_key, "MAX_FILE_SIZE", 13);
+ U_STRING_DECL(computemd5_key, "COMPUTE_MD5", 11);
+ U_STRING_DECL(computesha1_key, "COMPUTE_SHA1", 12);
static zend_bool did_string_init = FALSE;
int llen = 0;
+ int compute_md5=0, compute_sha1=0;
+ PHP_MD5_CTX md5_context;
+ unsigned char md5_digest[16];
+ char md5_ascii_string[33];
+ PHP_SHA1_CTX sha1_context;
+ unsigned char sha1_digest[20];
+ char sha1_ascii_string[41];
+ UChar *md5_string=NULL, *sha1_string=NULL;
if (SG(request_info).content_length > SG(post_max_size)) {
sapi_module.sapi_error(E_WARNING, "POST Content-Length of %ld
bytes exceeds the limit of %ld bytes", SG(request_info).content_length,
SG(post_max_size));
@@ -1069,6 +1081,8 @@
U_STRING_INIT(name_key, "name", 4);
U_STRING_INIT(filename_key, "filename", 8);
U_STRING_INIT(maxfilesize_key, "MAX_FILE_SIZE", 13);
+ U_STRING_INIT(computemd5_key, "COMPUTE_MD5", 11);
+ U_STRING_INIT(computesha1_key, "COMPUTE_SHA1", 12);
did_string_init = TRUE;
}
@@ -1165,6 +1179,12 @@
if (!u_strcasecmp(param, maxfilesize_key, 0)) {
max_file_size = zend_u_strtol(u_val,
NULL, 10);
}
+ else if (!u_strcasecmp(param, computemd5_key,
0)) {
+ compute_md5 = zend_u_strtol(u_val,
NULL, 10);
+ }
+ else if (!u_strcasecmp(param, computesha1_key,
0)) {
+ compute_sha1 = zend_u_strtol(u_val,
NULL, 10);
+ }
var_done:
efree(param);
@@ -1247,6 +1267,14 @@
cancel_upload = UPLOAD_ERROR_D;
}
+ if (compute_md5) {
+ PHP_MD5Init(&md5_context);
+ }
+
+ if (compute_sha1) {
+ PHP_SHA1Init(&sha1_context);
+ }
+
end = 0;
while (!cancel_upload && (blen =
multipart_buffer_read(mbuff, buff, sizeof(buff), &end TSRMLS_CC)))
{
@@ -1263,6 +1291,13 @@
} else if (blen > 0) {
wlen = fwrite(buff, 1, blen, fp);
+ if (compute_md5) {
+ PHP_MD5Update(&md5_context,
buff, blen);
+ }
+ if (compute_sha1) {
+ PHP_SHA1Update(&sha1_context,
buff, blen);
+ }
+
if (wlen < blen) {
#if DEBUG_FILE_UPLOAD
sapi_module.sapi_error(E_NOTICE, "Only %d bytes were written, expected to write
%d", wlen, blen);
@@ -1302,6 +1337,17 @@
zend_u_hash_add(SG(rfc1867_uploaded_files),
IS_UNICODE, ZSTR(temp_filename), u_strlen(temp_filename) + 1, &temp_filename,
sizeof(UChar *), NULL);
}
+ if (compute_md5) {
+
Re: [PHP-DEV] [RFC] Starting 5.3
Marcus Boerger wrote: Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Fri, 4 May 2007, Lukas Kahwe Smith wrote: > Ilia Alshanetsky wrote: > > > > On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote: > > > > > Yes, to me the question is only if we want to give the message that > > > software producers should be able to expect phar to be there on 99% of the > > > systems. Thats the only way that phar has a good chance of really taking > > > off as a php code distribution approach. > > > > It sounds like the merits of having phar is would only be apparent after it > > is included in the core and everyone starts using it because of that. This > > won't happen simply because most software producers can't rely on extensions > > that are only available in version X. > > No, the point is that if we want to push something, we need to add it sooner > rather than later, because there will be a delay anyways. Also simply by > putting it into core, we make sure that phar gets into the long terms plans of > users (which are then more likely to accept the transition pain, because they > know its going to be around and maintained). Right, so the question is whether we want to push it or not. What would be good reasons for adding phar to the core? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: It means you can run a phar file. How is that so hard to understand. It is not hard to understand. What seems to be hard to understand is that the scenario you describe is by no way the only scenario PHP files run in. Not all applications are single entry point and of those that are, not all applications are suitable to work in non-filesystem environment. Thus using phar in applications not specifically designed for it and in environments which presume files are in filesystem might prove harder than some think. So if you are wondering about use cases, the PEAR installer is a good example. Generally I would say phar lends itself for self installing applications, but also for applications you run infrequently, that are not that performance critical (which does not mean you want them to run extra slow either) and where you want minimal fuss in keeping an uptodate version. I do not see phar's be used as the runtime after installation for most applications of course. But a sizeable number of them could be run this way. Also it is one of those cases of "build it and they will come". So once we put this into core, people will take notice, tools will be developed, others will be adapted to become compatible etc. Maybe we should for a moment shift the discussion from "if its useful" (because several half way smart people have said it is), to "is it technically sensibly implemented". Just give these guys the benefit of the doubt on the usefulness part and make sure its good on the implementation part. regards, Lukas regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
On Sun, 6 May 2007, Mike Robinson wrote: > It could well be the last chance to get the mail() logger into 5.x as well, > and IMHO a lot of > people are waiting for this that can't/won't migrate to PHP6 quickly. There is no reason why that can't go into PHP 5.2.3. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote: Marcus Boerger wrote: Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. .. even though it does not require Phar extension at all. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Sun, 6 May 2007, Lukas Kahwe Smith wrote: > Ilia Alshanetsky wrote: > > IMHO one good reason to start a new branch for 5.x would be the ability to > > get rid off register_globals and magic_quotes in the 5 series without having > > to wait for PHP6 to come around. > > What would be the goal of that? Making it less painful to migrate to PHP 6.x > since they already face similar pain when staying in the active 5.x branch? Well, as you know some developers do not really care about PHP 6 and just leave it lying around without the proper merged from stuff that are put in PHP_5_2 at the moment. IMO this is just another attempt to stall PHP 6 developed (and adoption). I would be against merging those two things back to PHP_5_2. There is no compelling reason to do so. However, something that *is* a good reason is some lower level engine stuff that people will actually benefit from. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Lester Caine wrote: > Andi Gutmans wrote: > > I see no value in making compatibility breaks in 5.x and not in the next > > major version. As it is we drive a lot of our users crazy. We already > > agreed this is a 6.x thing. > > > IMHO one good reason to start a new branch for 5.x would be the ability to > > > get rid off register_globals and magic_quotes in the 5 series without > > > having to wait for PHP6 to come around. > > It seems to me that there are even more people around with their own agendas > today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've > stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for > me, so my next step WOULD be PHP6. For those of us who have already 'dropped' > register_globals and magic_quotes in our code, forcing people who have not yet > had time to make the move seems a little heavy handed. PHP6 will need a major > porting exercise, so keep it until then. > > As for phar? It sounds a little like PDO. No one has time to work on the > Firebird PDO driver because we still need the main driver to provide the > functions PDO does not support. Proper discussion and development of elements > that are planned to become main stream would be nice, and not the apparently > current method of 'I'm doing this in the next release because I want it!' Do > we need phar? Is it fully operational on all platforms? How will the currently > registered dependencies be addressed? IF it goes into the main distribution > presumably the installers are going to be extended to support it's server > requirements. Is that appropriate 'mid cycle'? > > It WOULD be nice to spend some time inside the PHP code base, but at present > all spare time seems to be spent monitoring and testing all the changes to the > releases and always playing catch up. > > PHP6 is the next release - PHP5 should now be tied down and put on the same > basis as PHP4 before we end up with even more private initiatives creating > even more mayhem :( > If people want these changes why aren't they working to get PHP6 out? Amen, besides that you should use php 5.2 and not 5.1.6 ;-) regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Antony Dovgal wrote: > On 05/06/2007 10:11 PM, Ilia Alshanetsky wrote: > > IMHO one good reason to start a new branch for 5.x would be the ability to > > get rid off register_globals and magic_quotes in the 5 series without > > having to wait for PHP6 to come around. > > That's exactly the reason I'm against creating 5_3 branch at this moment - I'm > afraid that you (and everybody else) will start patching it and 5_2 will > become 4_4 as it is now - security fixes only.. once in a month.. maybe.. or > maybe not. > You would be busy with 5_3, even though there is enough work in 5_2 branch. Yes, and development should not be done in a branch anyway, but in HEAD. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Antony Dovgal wrote: On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote: Marcus Boerger wrote: Well alot of people make use of our PEAR project. It comes with a bunch of nice sub projects. And even some external (as in non PHP) applications and projects make use of it. Providing a better internal infrastructure would be very nice here. Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. .. even though it does not require Phar extension at all. Yup, since its only leveraging phar for installation. It would be nice to also be able to try out a new version of PEAR efficiently without having to install any files besides running the phar. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
Really? I've used this pseudonym for years and years, dozens and dozens of places. I've got a patch checked into Mozilla using it. I've communicated with other developers in a wide variety of places... I cannot recall anyone saying it was rude of me to use such a name. In fact, most people like it. They understand the realities of identity theft (among other things), and why I choose not to post any personal information anywhere if at all possible. I don't really understand why it would be rude to post using a pseudonym on a relatively unimportant developer's newsgroup. -[Unknown] Original Message It's not worse than not using a real name to post with Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Derick Rethans wrote: PHP6 is the next release - PHP5 should now be tied down and put on the same basis as PHP4 before we end up with even more private initiatives creating even more mayhem :( If people want these changes why aren't they working to get PHP6 out? Amen, besides that you should use php 5.2 and not 5.1.6 ;-) Perhaps when I get some time to find out why the code will not run on 5.2 but is fine on 5.1.6 ;) But now need to set the test machine up with 5.2.2 and start testing again. If we knew that there were no problems installing an update life would be easier, but the time it takes to fully test all options every time simply BECAUSE we know things will need changing . -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: > As for phar? It sounds a little like PDO. No one has time to work on the > Firebird PDO driver because we still need the main driver to provide the > functions PDO does not support. Proper discussion and development of > elements that are planned to become main stream would be nice, and not > the apparently current method of 'I'm doing this in the next release > because I want it!' Do we need phar? Is it fully operational on all > platforms? How will the currently registered dependencies be addressed? > IF it goes into the main distribution presumably the installers are > going to be extended to support it's server requirements. Is that > appropriate 'mid cycle'? Hi Lester, Phar does not require any external dependencies to read .phar files. Optional extension dependencies include SPL and hash. It is fully operational on all platforms because it uses the streams layer to read the underlying .phar file, and it has no "server requirements" It may be helpful to understand where phar came from. I've been happily developing PHP_Archive (http://pear.php.net/PHP_Archive) and using it to package up PEAR releases since PHP 5.2.0 - in production. PHP_Archive relies upon a user stream wrapper to function, but works great. Unfortunately, as of PHP 6, the plan is to mark all user streams as being remote, regardless of what they actually do. Because of this, PHP_Archive will no longer work on *any* system without php.ini changes. This effectively kills the format. The phar extension, being a C-based extension, is allowed to mark itself as a local, non-remote stream, and will therefore still work. Phar has had many extra features added since this original porting of PHP -> C. One of the significant features allows a mapping of a phar to its extracted location on disk. There are plans to implement a simple but effective (optional) front controller function to simplify pharring of web apps. Phar is not yet perfect, but is also not NEARLY as complex as PDO. There is no comparison. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Mike Robinson wrote: It could well be the last chance to get the mail() logger into 5.x as well, and IMHO a lot of people are waiting for this that can't/won't migrate to PHP6 quickly. i have added it to the open discussion items for 5.2.3: http://oss.backendmedia.com/PhP52 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug? Raw POST data in PHP 5.2.2, take two
On 5/7/07, Unknown W. Brackets <[EMAIL PROTECTED]> wrote: Really? I've used this pseudonym for years and years, dozens and dozens of places. I've got a patch checked into Mozilla using it. I've communicated with other developers in a wide variety of places... I cannot recall anyone saying it was rude of me to use such a name. In fact, most people like it. They understand the realities of identity theft (among other things), and why I choose not to post any personal information anywhere if at all possible. I don't really understand why it would be rude to post using a pseudonym on a relatively unimportant developer's newsgroup. -[Unknown] Original Message > It's not worse than not using a real name to post with > > Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ok, enough.. we are we talking about a bug or personal differents here ? Please take it to private if you feel like debating what is what and who is who. Unknown person, maybe it was curt, so what ? Life goes on... Anyone has an answer/tests to that bug* so we can stop this discussion ? :) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Gregory Beaver wrote: Phar is not yet perfect, but is also not NEARLY as complex as PDO. There is no comparison. The 'comparison' was in the way these packages get added without proper investigation ;) Someone decides that THIS is how it will be done, and that is what happens :( and we have to live with the consequences. How would I use 'phar' with the four thousand files that make up bitweaver? I have had a quick look, but I don't yet see how I handle all the installation and management options for installing and updating packages that bitweaver has been designed to support. ADOdb and smarty provide the core libraries, and the liberty shell is built on those. Only those packages that are needed are download to the target system. I suspect we would have to build phar files for each package, but currently styles and themes can easily be managed via a few file changes, something that phar would seem to make a lot more difficult. Private tweaks to the libraries provide performance and operational improvements that would not be possible if ADOdb or smarty were supplied 'packed'. But without example phar libraries to look at and pull apart proper investigation is difficult - as people have already said. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: > Andi Gutmans wrote: >> I see no value in making compatibility breaks in 5.x and not in the next >> major version. As it is we drive a lot of our users crazy. We already >> agreed this is a 6.x thing. >>> IMHO one good reason to start a new branch for 5.x would be the >>> ability to get rid off register_globals and magic_quotes in the 5 >>> series without having to wait for PHP6 to come around. > > It seems to me that there are even more people around with their own > agendas today. I don't think there are that many agendas, just more constituents of each. * admins who don't want binary compatibility breaks on subversion bumps, lest they start rebuilding all sorts of things beyond php itself. * admins and users who are sick of having things that 'just worked' broken even at a subversion bump, and who don't want to see anything deprecated until PHP6. * security folk who want frequently-abused features deprecated yesterday. * users who want the bleeding edge new toys and features. and -most importantly- * developers who want to implement new toys and push them out there to the admin and user communities tomorrow. Pride of authorship, usefulness, encouraging the health of the community, and all that. * developers who want to constrain growth so that the users have a more stable platform to use and they can follow all of the changes. They are most important because PHP -is- its developers. The only question, how to reconcile this most critical constituency with the other communities, such that all of the communities are mostly-happy. This probably only works if things don't get broken between 5.2.2 and 5.2.3, only absolutely manditory breakage occurs from 5.2 to 5.3, some wiggle room for cool new things is left open in 5.2.3 and 5.3, and finally that some of the more 'international' devs, users and admins work focus together on a 6.0 end-result, since they are the ones who needed the unicode implementation about five years ago. These are the same battles we all face at many projects (I'm hidden over at httpd, apr, etc etc) and the conclusion is usually the same. Pick a versioning policy, stick to it, and otherwise don't get in the way of dev's enthusiasm. [If any users/admins are insulted, mea culpa. Consider that there would be no PHP for you to use/admin without your dedicated developers. It's open source - if it broke, you still have both halves.] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Antony Dovgal wrote: > On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote: >> Marcus Boerger wrote: >> >>> Well alot of people make use of our PEAR project. It comes with a >>> bunch of >>> nice sub projects. And even some external (as in non PHP) >>> applications and >>> projects make use of it. Providing a better internal infrastructure >>> would be >>> very nice here. >> >> Stas, not sure if you are aware of this, but the PEAR installer has >> gotten wide adoption as a deployment tool. > > .. even though it does not require Phar extension at all. .. and (again) let me be clear: PHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions. Without phar, the entire concept that the phar:// stream wrapper is based upon ceases to be a possibility for wide distribution. So, yes, this will require the Phar extension or simply cease to exist as a possibility in the near future. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: > Gregory Beaver wrote: >> Phar is not yet perfect, but is also not NEARLY as complex as PDO. >> There is no comparison. > > The 'comparison' was in the way these packages get added without proper > investigation ;) Someone decides that THIS is how it will be done, and > that is what happens :( and we have to live with the consequences. Please, this is ridiculous, your response is completely out of proportion to what is happening. Marcus proposed the addition of phar to core in 5.3, and is now asking for public comment. > How would I use 'phar' with the four thousand files that make up > bitweaver? I have had a quick look, but I don't yet see how I handle all > the installation and management options for installing and updating > packages that bitweaver has been designed to support. ADOdb and smarty > provide the core libraries, and the liberty shell is built on those. > Only those packages that are needed are download to the target system. I > suspect we would have to build phar files for each package, but > currently styles and themes can easily be managed via a few file > changes, something that phar would seem to make a lot more difficult. > Private tweaks to the libraries provide performance and operational > improvements that would not be possible if ADOdb or smarty were supplied > 'packed'. But without example phar libraries to look at and pull apart > proper investigation is difficult - as people have already said. phar is best for self-contained libraries or applications that do not need to modify their source code. Many applications (like phpmyadmin) do configuration by modifying a source code file and then including it. This practice would require that the phar.read_only INI setting be off in php.ini (it is on by default). Also useful and not yet implemented would be to allow include_path to have a phar:// archive, as many issues with "pharring" applications would no longer exist. Controversy doesn't even begin to describe the reaction I expect from this suggestion, however. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 11:50:15 AM, you wrote: >> I think one advantage of phar is that it is backed by PEAR tools that > I think it's a disadvantage. So you would like to drop PEAR? > distributing PEAR files - but when we > talking about PHP-wide policy I don't think we should recommend people > running their applications out of phar files. We are not speaking of a policy here. We are not Java wherenothing else then whatever *AR's work. Weare PHP and give options. And we try to make it as easy as possible. Here is something that would make a lot of peoples stuff way easier. Because believe it or not a bunch ofpeople use PEAR. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 7-May-07, at 2:24 PM, Marcus Boerger wrote: Because believe it or not a bunch ofpeople use PEAR. Scary, ain't it? ;-) Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/7/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: On 7-May-07, at 2:24 PM, Marcus Boerger wrote: > Because believe it or not a bunch ofpeople use PEAR. > Scary, ain't it? ;-) Totally other discussion, but I don't think it's scary, we are pushing for much more solid packages and more secure *applications*. (Good QA, Good work actually done) PEAR does have some pretty ugly packages and I can't say otherwise, however there's a lot of useful tools and good developers within pear :) Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
So you would like to drop PEAR? Where you get these ideas I wonder? I want to use universally used formats. We are not speaking of a policy here. We are not Java wherenothing else then I think we are. Endorsing phar as runtime format is endorsing policy, as I see it. whatever *AR's work. Weare PHP and give options. And we try to make it as easy as possible. Here is something that would make a lot of peoples stuff way easier. Because believe it or not a bunch of people use PEAR. All power to them, but why should they use phar as runtime format? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stas, not sure if you are aware of this, but the PEAR installer has gotten wide adoption as a deployment tool. Meaning a lot of people are running apps packaged in phar's? Could you bring forward some examples? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
David Coallier wrote: > Anyone has an answer/tests to that bug* so we can stop this discussion ? :) The bug has apparently been fixed in CVS. Haven't had a chance to test it, but will do as soon as possible. Now the question is: When can we expect an update? I see people talking about what should go into PHP 5.2.3. How about "this bugfix, possibly a few others, and then release it ASAP"? As in by the end of this week (or thereabouts)? This bug affects a lot of sites that use XML-RPC communication of some form or another. Quite a lot of those nifty Web 2.0 sites, I would assume. And since people will be updating quickly due to the security issues fixed with 5.2.2, they may be in for a surprise. So can we have an update soon, please? bye, Dirk P.S. And if anyone would be willing to answer some of the questions from my original post, I'd be grateful. -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev schrieb: > All power to them, but why should they use phar as runtime format? Maybe we could agree on using phar as a means of deploying PHP code, as I pointed out earlier? Otherwise it seems, as Greg has pointed out, that PEAR as it is will become pretty useless with the release of PHP6. Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
PHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions. I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. What happens we need next application using named streams? Another extension into main PHP source whose purpose is to duplicate PHP code and work around our own security model? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] how does Phar actually work?
Hi, There has been a bit of inevitable FUD with phar. Although the manual (http://php.net/phar) describes a fair amount of how phar works, the design decisions are not documented. Originally, the phar stream wrapper was a userspace thing. Davey Shafik designed it to take advantage of a neat loophole in the design of the tar file format so that a valid tar could be run by PHP without needing to have the phar stream wrapper loaded. This was great until I started using it to run the PEAR Installer. The performance hit was tremendous, as every newly included file required scanning the entire file, header by header, until we found the needed file. Worst case, it meant loading megabytes of information just to locate a file. The zip file format has the same limitation - the entire archive needs to be scanned. Both of these formats were not designed for random access in the way a traditional filesystem is designed. In fact, I could not find an example of a archive format that is designed for this. As such, borrowing from the design of disk filesystems, I created a new format that is very small and processes very quickly. It is so much faster, I can't detect a difference in performance running the PEAR installer off of the disk and running it out of a phar. I am sure there is a difference that apache benchmark would detect because of extra load-in time of the file manifest. The way phar works now is a file manifest is at the start of the phar archive (similar to a directory file in traditional filesystems). Each file has a manifest entry containing the file name, size of the file, and offset into the archive plus some flags and optional meta-data. The manifest is currently limited in size to 1 MB, so some applications probably would not be possible to phar under the current design. Each phar has a loader stub, which can be any php code, but must contain the __HALT_COMPILER(); token. This will allow creating phars that also contain PHP_Archive to work under conditions where the phar extension is disabled. It is the loader stub that makes it possible to run a phar with plain vanilla PHP. I see two possible solutions to the concerns raised by others. 1) don't worry, be happy 2) re-design the phar file format such that it is a tar again, and put the manifest for quick loading in one of the first files of the tar archive. If I had thought #2 was a good idea, I would have already done it, so there is my opinion. One basic assumption I would like to raise here is that nobody is going to download a .phar archive who does not already have PHP. Does this assumption sound sane? If so, I would like to provide some simple scripts for unpharring and repharring a .phar archive. This is not hard to do with a 5-line PHP script. One of the big questions I would have though would be for xdebug (hi Derick) and designers of IDEs, as it would be good to ensure that it is possible to step through a phar, or even to dump the source line with an error message. These, to me, seem to be the most pressing disadvantages of phar currently - it becomes much harder to debug a problem in a PHP script when it is stuffed into a phar. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Maybe we could agree on using phar as a means of deploying PHP code, as I pointed out earlier? Otherwise it seems, as Greg has pointed out, that PEAR as it is will become pretty useless with the release of PHP6. We could. But you don't need no extensions for that. If PHP6 makes PEAR useless, we probably should deal with *that* problem, shouldn't we? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stefan Priebsch wrote: > Stanislav Malyshev schrieb: >> All power to them, but why should they use phar as runtime format? > > Maybe we could agree on using phar as a means of deploying PHP code, as > I pointed out earlier? Otherwise it seems, as Greg has pointed out, that > PEAR as it is will become pretty useless with the release of PHP6. Correction: the *installation* process for PEAR will have to be reverted to the way it worked in PHP 4. PEAR is unaffected by these changes. There are other changes that affect PEAR, which is why we are moving all packages to PHP 5+ currently. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Gregory Beaver schrieb: > Correction: the *installation* process for PEAR will have to be reverted > to the way it worked in PHP 4. PEAR is unaffected by these changes. Which, from the end user's viewpoint, makes PEAR useless because they cannot install PEAR in the first place. That's what I meant. > There are other changes that affect PEAR, which is why we are moving all > packages to PHP 5+ currently. Could you please elaborate on that a little more? Kind regards, Stefan -- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
So if you are wondering about use cases, the PEAR installer is a good example. Generally I would say phar lends itself for self installing Let's separate phar as installer format and phar as runtime format. Only problem I have with the former is that it's custom NIH-syndrome-enabled format which no tools except PEAR can work with. I don't have any problem with the idea of having distribution format inside PHP toolkit or the intent of the project, on the contrary - I think it's a great think that should be taken even further - probably up to something like InstallShield.php ;) As for phar in runtime I think moving away from filesystem would create more problems than solve. Of course, there are people that think the opposite. Also it is one of those cases of "build it and they will come". So once we put this into core, people will take notice, tools will be developed, others will be adapted to become compatible etc. We don't need phar extension in the core to make phar installer, as far as I understand. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/07/2007 10:39 PM, Stanislav Malyshev wrote: PHP_Archive-based phar archives will no longer work once allow_url_include is off and user streams wrappers are marked as remote. So, it won't work with 100% of new installations in future PHP versions. I guess we are solving the wrong problem. We have: 1. phar needs script-defined named streams 2. Named streams are prohibited by some config option 3. Let's pretend this stream is not actually what it is 4. Let's create whole new extension for that and put it into main PHP Exactly what I said in IRC earlier today. Both problem and solution look weird. I think this process is wrong. If we have problem with names streams usage in apps, we should seek solutions there, not invent modules just to work around the problem we ourselves create. What happens we need next application using named streams? Another extension into main PHP source whose purpose is to duplicate PHP code and work around our own security model? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 5/7/07, Antony Dovgal <[EMAIL PROTECTED]> wrote: On 05/07/2007 10:39 PM, Stanislav Malyshev wrote: >> PHP_Archive-based phar archives will no longer work once >> allow_url_include is off and user streams wrappers are marked as remote. >> So, it won't work with 100% of new installations in future PHP versions. > > I guess we are solving the wrong problem. We have: > 1. phar needs script-defined named streams > 2. Named streams are prohibited by some config option > 3. Let's pretend this stream is not actually what it is > 4. Let's create whole new extension for that and put it into main PHP Exactly what I said in IRC earlier today. Both problem and solution look weird. > I think this process is wrong. If we have problem with names streams > usage in apps, we should seek solutions there, not invent modules just > to work around the problem we ourselves create. What happens we need > next application using named streams? Another extension into main PHP > source whose purpose is to duplicate PHP code and work around our own > security model? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ok just so there's no confusion.. Here's 2 examples why PEAR and phar are both useful (If you need more detailed examples (file names, etc I can also draw up something) 1) Phar: You can use phar for instance if you deploy all your own scripts, etc. A normal application without third party libraries bundled (Otherwise of couse you can store your third script in your phar and just make a new release when the third-script updates) etc. The idea of the phar is to make it easy to deploy. Which is good. 2) Pear: Pear has channels which make it really easy to deploy applications that are depending on different channels (third party scripts) which make it easy to both install and udpate. You wrap your application in your package name which you distribute through the SOMENAME.com channel, then you can also use another channel (the third party script) by using channel-discover and download/easy update the third-party scripts using pear upgrade SOMEOTHERCHANNEL.com's package name. -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: how does Phar actually work?
The stub could also easily include code to allow for an extraction flag to work. So you could run php my.phar --extract and have the code dumped to the FS as it originally was. The choice to add these things (the stub and the extract flag), is just that, a choice. The same as choosing short tags, or relying on magic_quotes* etc. Of course, sane defaults when creating phars, is something we can decide on as things move on, I would vote for having both PHP_Archive and the --extract flag code inserted by default, this would solve the issues IMO. - Davey Gregory Beaver wrote: Hi, There has been a bit of inevitable FUD with phar. Although the manual (http://php.net/phar) describes a fair amount of how phar works, the design decisions are not documented. Originally, the phar stream wrapper was a userspace thing. Davey Shafik designed it to take advantage of a neat loophole in the design of the tar file format so that a valid tar could be run by PHP without needing to have the phar stream wrapper loaded. This was great until I started using it to run the PEAR Installer. The performance hit was tremendous, as every newly included file required scanning the entire file, header by header, until we found the needed file. Worst case, it meant loading megabytes of information just to locate a file. The zip file format has the same limitation - the entire archive needs to be scanned. Both of these formats were not designed for random access in the way a traditional filesystem is designed. In fact, I could not find an example of a archive format that is designed for this. As such, borrowing from the design of disk filesystems, I created a new format that is very small and processes very quickly. It is so much faster, I can't detect a difference in performance running the PEAR installer off of the disk and running it out of a phar. I am sure there is a difference that apache benchmark would detect because of extra load-in time of the file manifest. The way phar works now is a file manifest is at the start of the phar archive (similar to a directory file in traditional filesystems). Each file has a manifest entry containing the file name, size of the file, and offset into the archive plus some flags and optional meta-data. The manifest is currently limited in size to 1 MB, so some applications probably would not be possible to phar under the current design. Each phar has a loader stub, which can be any php code, but must contain the __HALT_COMPILER(); token. This will allow creating phars that also contain PHP_Archive to work under conditions where the phar extension is disabled. It is the loader stub that makes it possible to run a phar with plain vanilla PHP. I see two possible solutions to the concerns raised by others. 1) don't worry, be happy 2) re-design the phar file format such that it is a tar again, and put the manifest for quick loading in one of the first files of the tar archive. If I had thought #2 was a good idea, I would have already done it, so there is my opinion. One basic assumption I would like to raise here is that nobody is going to download a .phar archive who does not already have PHP. Does this assumption sound sane? If so, I would like to provide some simple scripts for unpharring and repharring a .phar archive. This is not hard to do with a 5-line PHP script. One of the big questions I would have though would be for xdebug (hi Derick) and designers of IDEs, as it would be good to ensure that it is possible to step through a phar, or even to dump the source line with an error message. These, to me, seem to be the most pressing disadvantages of phar currently - it becomes much harder to debug a problem in a PHP script when it is stuffed into a phar. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
On 7-May-07, at 2:35 PM, Dirk Haun wrote: David Coallier wrote: Anyone has an answer/tests to that bug* so we can stop this discussion ? :) The bug has apparently been fixed in CVS. Haven't had a chance to test it, but will do as soon as possible. Please let me know how it works out. One interesting feature of the old code is that HTTP_RAW_POST_DATA could be present even when the INI option controlling its creation was off, this was a bug and will not be re-instated. Now the question is: When can we expect an update? I see people talking about what should go into PHP 5.2.3. How about "this bugfix, possibly a few others, and then release it ASAP"? As in by the end of this week (or thereabouts)? I suspect in a week or two. Definitely sooner then later. This bug affects a lot of sites that use XML-RPC communication of some form or another. Quite a lot of those nifty Web 2.0 sites, I would assume. And since people will be updating quickly due to the security issues fixed with 5.2.2, they may be in for a surprise. I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but rather JSON or REST. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Monday, May 7, 2007, 8:50:18 PM, you wrote: >> So if you are wondering about use cases, the PEAR installer is a good >> example. Generally I would say phar lends itself for self installing > Let's separate phar as installer format and phar as runtime format. Only > problem I have with the former is that it's custom NIH-syndrome-enabled > format which no tools except PEAR can work with. I don't have any > problem with the idea of having distribution format inside PHP toolkit > or the intent of the project, on the contrary - I think it's a great > think that should be taken even further - probably up to something like > InstallShield.php ;) Phew, good. > As for phar in runtime I think moving away from filesystem would create > more problems than solve. Of course, there are people that think the > opposite. Agreed. It may often bring a bunch of problems. However being able to have some stuff kept in a package, like a database driver, is a good thing. This is actually what is donewith most JARs. If we could do that with the same format we use as a distribution format, then suddenly some nice stuff is possibly. You use phar packaged fileto download some packages that you only use as includes. Now you keep them in your web space, disallow access to ".phar" and include the actualfiles via "phar://...phar/...". As a sideeffect you can easily check that the package doesn't get changed. Now please note that from the beginning, I did not say that this is something we should promote as the absolute best thing. I am only saying that this is an option the pahr extension offers. >> Also it is one of those cases of "build it and they will come". So once >> we put this into core, people will take notice, tools will be developed, >> others will be adapted to become compatible etc. > We don't need phar extension in the core to make phar installer, as far > as I understand. We will need it: - by the time of PHP 6 - to be able to have PHARs without pretty big PHP_Archive stuff included - "include phar://" run easily and always And just to be certain, we are not trying to force anybody to use it. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: >> The bug has apparently been fixed in CVS. Haven't had a chance to test >> it, but will do as soon as possible. > >Please let me know how it works out. I've tested php5.2-200705071830.tar.gz from snaps.php.net and the bug seems to be fixed. Thanks. >One interesting feature of the >old code is that HTTP_RAW_POST_DATA could be present even when the >INI option controlling its creation was off, this was a bug and will >not be re-instated. I had a suspicion that something wasn't right there. No problem with that change - that's what the INI option is for. >> Now the question is: When can we expect an update? > >I suspect in a week or two. Definitely sooner then later. Sounds good. >I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but >rather JSON or REST. Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging weblog directories like Technorati. That's something like the backbone of the entire "blogosphere". bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: > > On 7-May-07, at 2:35 PM, Dirk Haun wrote: > >> David Coallier wrote: >> >>> Anyone has an answer/tests to that bug* so we can stop this >>> discussion ? :) >> >> The bug has apparently been fixed in CVS. Haven't had a chance to test >> it, but will do as soon as possible. > > Please let me know how it works out. One interesting feature of the old > code is that HTTP_RAW_POST_DATA could be present even when the INI > option controlling its creation was off, this was a bug and will not be > re-instated. I must have missed something. Did you change the documented behaviour that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an unknown content type? If so, that was most definitely not a bug and not something that should have been changed. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote: I must have missed something. Did you change the documented behaviour that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an unknown content type? If so, that was most definitely not a bug and not something that should have been changed. If lack of post handler is classified by an unknown content type then yes, where is it documented btw? Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
We will need it: - by the time of PHP 6 I think this problem should be fixed not by killing PEAR and converting it to PHP extensions but by fixing PHP 6 and enabling PEAR to work. - to be able to have PHARs without pretty big PHP_Archive stuff included It's for install, how big could it be? 20 K? If it's more, it can probably be rewritten to be shorter :) - "include phar://" run easily and always I'm not sure we want include phar:// because include($file) and include(realpath($file)) for example would work VERY different then. Think about poor library writers having to deal with these things. And just to be certain, we are not trying to force anybody to use it. I thought this was officially declared non-argument in scope of PHP discussions? ;) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: > > On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote: > >> I must have missed something. Did you change the documented behaviour >> that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an >> unknown content type? If so, that was most definitely not a bug and not >> something that should have been changed. > > If lack of post handler is classified by an unknown content type then > yes, where is it documented btw? Right where you would expect: http://www.php.net/manual/en/ini.core.php always_populate_raw_post_data boolean Always populate the $HTTP_RAW_POST_DATA containing the raw POST data. Otherwise, the variable is populated only with unrecognized MIME type of the data. However, the preferred method for accessing the raw POST data is php://input. $HTTP_RAW_POST_DATA is not available with enctype="multipart/form-data". The language could be clearer I suppose, but I don't think there is any mistaking what it means there. And this is also referred to in all sorts of other places in the documentation, books, articles and code examples. I thought this was a very well established behaviour, but I guess not. Please revert. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files
What purpose does this serve, exactly?... Seems like anybody who can intercept the upload and send bad file data can also send a matching MD5 for the bad data... Actually, re-reading the message clarified for me that you're doing this only to save the time of whatever it would take to do an MD5 for the file after its uploaded. Can you PLEASE make 100% certain that this is specifically documented to NOT be a "Security Feature" and it is NOT intended to indicate secure transmission of the file? Cuz I'm betting dollars to donuts that the masses of PHP scripters are going to immediately mis-use this for that exact purpose... On Mon, May 7, 2007 6:08 am, David Santinoli wrote: > > Hi, > I'm submitting a patch to perform "on the fly" MD5/SHA1 digest > calculation of a file uploaded via the HTTP POST method. Being > not uncommon for applications to require some digest of a freshly > uploaded file, doing the math directly in the buffer where the file is > being read can save some time. > > A similar patch was submitted in August 2004 and raised some interest, > but never got merged. > > Digest calculation is triggered by setting the special input fields > COMPUTE_MD5 and/or COMPUTE_SHA1 to a non-zero value: > > > > (note that these assignments must precede the > field, as in the MAX_FILE_SIZE case.) > > The result is found in the special variables > $_FILES[userfile]["md5"] and $_FILES[userfile]["sha1"]. > These variables are only defined upon request of the corresponding > digest. > > The patch was produced against the php6 CVS version of rfc1867.c > (1.190). > > Cheers, > David > -- > David Santinoli > Tieffe Sistemi S.r.l. viale Piceno 21, Milano > www.tieffesistemi.com tel. +39 02 45490882 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- 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
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
On Mon, May 7, 2007 2:30 pm, Dirk Haun wrote: > Ilia Alshanetsky wrote: >>I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but >>rather JSON or REST. > > Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging > weblog directories like Technorati. That's something like the backbone > of the entire "blogosphere". And sometimes ya gotta use what the other guy provides... Even if you think it's a Bad Idea. Yes, you could, maybe, run your own little middleman server to download/cache and serve in whatever format you want, but there are all kinds of real-world reasons why that might not be allowed/acceptable. -- 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
Re: [PHP-DEV] serialize and cache handling
can write this data to disk. So, you needs 20MB. If serialize (and of course unserialize) would be able to write directly to disk (or read directly from disk), you only needs 10MB. Actually having serialize/unserialize be able to write directly to a stream and read directly from a stream might be interesting, would probably improve working with things like large sessions or caching large data substantially. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
On Mon, May 7, 2007 1:17 am, Andi Gutmans wrote: > I see no value in making compatibility breaks in 5.x and not in the > next > major version. As it is we drive a lot of our users crazy. We already > agreed this is a 6.x thing. +1 If there has to be a 5.3, I'd want to see features that: are incredibly useful/important to the masses (input filtering) aren't easily tweaked in 5.2.x don't break anything (i.e., only new functions/extensions/features) If that ends up being an empty set, then don't even mess with 5.3 and focus on 6.0 :-) -- 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
Re: [PHP-DEV] [RFC] Starting 5.3
Stefan Priebsch wrote: > Gregory Beaver schrieb: > >> Correction: the *installation* process for PEAR will have to be reverted >> to the way it worked in PHP 4. PEAR is unaffected by these changes. >> > > Which, from the end user's viewpoint, makes PEAR useless because they > cannot install PEAR in the first place. That's what I meant. > What? PEAR has been distributed successfully with PHP since version 4.3. From the end user's viewpoint, there is no difference. go-pear.bat = go-pear.bat on windows, "make install-pear" = "make install-pear" on unix. The difference is in terms of the maintainers of PEAR, who will have to do a lot more work in order to synchronize new releases of PEAR than we do now. >> There are other changes that affect PEAR, which is why we are moving all >> packages to PHP 5+ currently. >> > > Could you please elaborate on that a little more? Not in this mailing list please. You are welcome to search the archives of pear-core and pear-dev, there has been a lot of discussion of PHP 5 and PEAR. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serialize and cache handling
Stanislav Malyshev wrote: can write this data to disk. So, you needs 20MB. If serialize (and of course unserialize) would be able to write directly to disk (or read directly from disk), you only needs 10MB. Actually having serialize/unserialize be able to write directly to a stream and read directly from a stream might be interesting, would probably improve working with things like large sessions or caching large data substantially. Indeed, especially since this is the most common use case. Maybe it should optionally also return an md5 of the written data. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: how does Phar actually work?
Gregory Beaver wrote: [snip] > megabytes of information just to locate a file. The zip file format has > the same limitation - the entire archive needs to be scanned. > > Both of these formats were not designed for random access in the way a > traditional filesystem is designed. In fact, I could not find an > example of a archive format that is designed for this. Josh Eichorn challenged this assertion on IRC, and so I took another look at the zip file format. It turns out, I was wrong - the format has something called a "central directory" at the end of the file, which is the equivalent to the manifest that phar uses. I apologize for the misrepresentation. Because the .zip file format cannot be parsed directly by PHP in the way that a phar archive can (in other words "php somefile.zip" yields gibberish, whereas "php somefile.phar" allows php loader execution), in order to use this for the phar file format, it would require some changes to PHP itself. In other words, php would do better to simply port over Java's jar stuff rather than phar if this is what people want (to be perfectly clear I'm not volunteering to do this). Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Hello,
I am getting a SIGSEGV when compiling php-5.2.2.
gdb breaks up at the if statement of the following function
static void php_apache_add_version(apr_pool_t *p)
{
TSRMLS_FETCH();
if (PG(expose_php)) {
ap_add_version_component(p, "PHP/" PHP_VERSION);
}
}
It only occurs when --enable-maintainer-zts is used.
main/php_globals.h:
# define PG(v) TSRMG(core_globals_id, php_core_globals *, v)
extern PHPAPI int core_globals_id;
#else
# define PG(v) (core_globals.v)
extern ZEND_API struct _php_core_globals core_globals;
#endif
TSRM/TSRM.h
#define TSRM_UNSHUFFLE_RSRC_ID(rsrc_id) ((rsrc_id)-1)
#define TSRMG(id, type, element)(((type) (*((void ***) tsrm_ls))
[TSRM_UNSHUFFLE_RSRC_ID(id)])->element)
GDB tells me that core_globals_id == 0 which leads to an index of -1 -- if I
interpret the results correctly.
Best Regards,
Oliver
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Passthrough MD5/SHA1 calculation of uploaded files
Ditto Richard's comments about false-implications of security, but I'd also like to add that *IF* folks decide on the whole that this is worth adding, it should be done more generically than a setting for md5 and a setting for sha1. e.g. or or or whatever hash algo you're looking for. The implementations in ext/hash can be used and the resulting code in main/rfc1867.c will wind up being simpler (since you'll be using the unified hash API rather than the individual md5/sha1 APIs). If someone (for some reason) has ext/hash disabled (it's enabled-by-default since 5.1.2), then they just won't get a hash. That's what package requirements and documentation are for. -Sara P.S. - Suggestions aside, I'm -1 on it. Richard Lynch wrote: What purpose does this serve, exactly?... Seems like anybody who can intercept the upload and send bad file data can also send a matching MD5 for the bad data... Actually, re-reading the message clarified for me that you're doing this only to save the time of whatever it would take to do an MD5 for the file after its uploaded. Can you PLEASE make 100% certain that this is specifically documented to NOT be a "Security Feature" and it is NOT intended to indicate secure transmission of the file? Cuz I'm betting dollars to donuts that the masses of PHP scripters are going to immediately mis-use this for that exact purpose... On Mon, May 7, 2007 6:08 am, David Santinoli wrote: Hi, I'm submitting a patch to perform "on the fly" MD5/SHA1 digest calculation of a file uploaded via the HTTP POST method. Being not uncommon for applications to require some digest of a freshly uploaded file, doing the math directly in the buffer where the file is being read can save some time. A similar patch was submitted in August 2004 and raised some interest, but never got merged. Digest calculation is triggered by setting the special input fields COMPUTE_MD5 and/or COMPUTE_SHA1 to a non-zero value: (note that these assignments must precede the field, as in the MAX_FILE_SIZE case.) The result is found in the special variables $_FILES[userfile]["md5"] and $_FILES[userfile]["sha1"]. These variables are only defined upon request of the corresponding digest. The patch was produced against the php6 CVS version of rfc1867.c (1.190). Cheers, David -- David Santinoli Tieffe Sistemi S.r.l. viale Piceno 21, Milano www.tieffesistemi.com tel. +39 02 45490882 -- 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] serialize and cache handling
On Mon, 7 May 2007, Lukas Kahwe Smith wrote: > Stanislav Malyshev wrote: > > > can write this data to disk. So, you needs 20MB. If serialize (and of > > > course unserialize) would be able to write directly to disk (or read > > > directly from disk), you only needs 10MB. > > > > Actually having serialize/unserialize be able to write directly to a stream > > and read directly from a stream might be interesting, would probably improve > > working with things like large sessions or caching large data substantially. > > Indeed, especially since this is the most common use case. Maybe it should > optionally also return an md5 of the written data. If we're to add this, make sure writes to the files are atomic. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: yanbin
I'm a PHP Programmer from China, I'd like to help translate phpdoc_zh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: > > We will need it: > > - by the time of PHP 6 > > I think this problem should be fixed not by killing PEAR and converting it to > PHP extensions but by fixing PHP 6 and enabling PEAR to work. Let me agree with Greg here. We can not go back to the PHP 4.x way of bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5 uses the phar, which works brilliantly. So the fix here is to make something *like* phar work with PHP 6 as well. If it was to be based on streams (which I think it can only be), then we *need* some way of marking this new user stream as being local in order for require and include to work on those. Making a hack in PHP to allow "phar://" streams to work is a bad idea, a C-extension can easily work here. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, 7 May 2007, Stanislav Malyshev wrote: > > PHP_Archive-based phar archives will no longer work once > > allow_url_include is off and user streams wrappers are marked as remote. > > So, it won't work with 100% of new installations in future PHP versions. > > I guess we are solving the wrong problem. We have: > 1. phar needs script-defined named streams > 2. Named streams are prohibited by some config option > 3. Let's pretend this stream is not actually what it is > 4. Let's create whole new extension for that and put it into main PHP > > I think this process is wrong. If we have problem with names streams usage in > apps, we should seek solutions there, not invent modules just to work around > the problem we ourselves create. So why don't you come up with a different "better" solution then? regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
