Re: [PHP-DEV] PHP-5.5 unpack change broke pecl/pear
Le 24/12/2012 04:16, Igor Wiedler a écrit : > Hi Internals, > > When test driving PHP-5.5 I ran into issues with a change of unpack > behaviour. Archive_Tar which is used by pecl and pear (`pecl install`) uses > unpack with the "a" format character. On 5.4 it strips trailing NUL bytes, on > 5.5 it does not. There is a new "Z" format character that can be used to get > the old behaviour. The point is, this change broke pecl, and will likely > break many other things in existence. > > Anthony has asked me to post to internals, so that you can re-visit the issue > and perhaps consider not breaking BC. > > If you decide that you want to keep the BC break, I will gladly submit a > patch for Archive_Tar. See http://pear.php.net/bugs/bug.php?id=19746 Remi. > > Thanks, > > Igor > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #23955: Cookie Max-Age attribute
It is briefly noted in the RFC (mine, not 6265) that negative values and 0 have the same effect. It's practically irrelevant which one is sent. My original commit actually did checks for negative values and sent zeros instead of them, but then somebody on github pointed out that they are legal, so I removed that logic. If not anything else, it saves a few lines of code. - Andrey Quoting Stas Malyshev : Hi! "Max-Age" would simply be added to all Set-Cookie headers, after the "Expires" attribute. I thought that was obvious, but I'll make sure to add a few examples to make it clearer. I think it makes sense, only note is that it makes no sense to set Max-Age to any negative number, especially as RFC 6265 treats all negative values and 0 as the same: If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time. Otherwise, let the expiry-time be the current date and time plus delta-seconds seconds. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
Hi! > I know this topic was opened a long time ago, but I would like to get > it resolved before 5.5 got released. I agree, it looks like a place where we could use improvement, current API is kind of dangerous. > A last solution would be to something similar to libcurl curl_formadd > (this one could be added to the previous one so that the old way work > but there is a more secure way to do it) : > > curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array( > 'firstname' => 'pierrick', > 'lastname' => array(CURLFORM_CONTENTS => 'charron'), > 'lastname' => array(CURLFORM_FILENAME => 'name.png', CURLFORM_FILE > => '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE => 'image/jpg') > ); > > One thing we have to think about this solution is if at some point we > want to allow sending array via curl, will it conflict ? I don't think we would allow sending arrays through curl, however there's another problem - theoretically, if user can access the data you put in $lastname variable, in many contexts it's not hard to put an array there either - i.e. if you have a form that has element lastname that posts to $lastname and then you do: curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array( 'lastname' => $lastname, /// etc. Then you could also create a form that posts to lastname[filename] and simulate this array too. So it's not a complete solution. I'm thinking maybe using separate option for files and deprecating the current one may be better idea. Unless somebody has even better solution :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
