Re: [PHP-DEV] $_FILES['name'] check
On Sun, Feb 16, 2020 at 6:24 PM Craig Francis wrote: > Just to check, at the moment, if I was an evil hacker, and was to run: > > curl -F 'file=@example.jpg;filename=../../../example.php' > https://example.com/upload/ > > The $_FILES['file']['name'] would be set to "example.php", where PHP has > removed the leading "../../../" (good to see). > > Does that happen simply because of this IE fix, where it uses _basename() > in the PHP source: > > > https://github.com/php/php-src/blob/0b4778c377a5753a0deb9cfc697d4f62acf93a29/main/rfc1867.c#L1144 Mostly, it seems. _basename will either be php_ap_basename[1] or php_mb_rfc1867_basename[2], and both of those handle the base name functionality regardless of platform. The comment's a little misleading, though. The original implementation[3] had a magic quotes check when compiled under WIN32, and that's what the comment's talking about. The comment's not saying that the basename call itself is for Windows only. [1]: https://github.com/php/php-src/blob/0b4778c377a5753a0deb9cfc697d4f62acf93a29/main/rfc1867.c#L558 [2]: https://github.com/php/php-src/blob/2e97ae91c8ac404be00050eef414b555aba45a1c/ext/mbstring/mbstring.c#L852 [3]: https://github.com/php/php-src/blob/7ee1fdb657f2a6da65087552e6dda8cf2f4bd1ef/main/rfc1867.c#L1088
Re: [PHP-DEV] Allow null variables to be decremented
On 18/02/2020 14:00, Nikita Popov wrote: Principally in favor of this change, I do think that ++ and -- should behave consistently if nothing else. We might want to consider giving the same treatment to false/true as well, which should be interpreted as 0/1. That is $foo++ / $foo-- should behave the same ways as $foo+=1, $foo-=1 for null, true, false. It seems odd to single out only "null" here. Additionally I would suggest a notice when trying to increment arrays, resources and objects, rather than just silently doing nothing. As long as it's just a notice, this should have minimal BC implications. Thanks. That seems a reasonably modest expansion, without getting into the deeper questions of string increments or fatal errors. For the record, the reason I singled out null is that it's the only type where ++ and -- behave differently from each other. With booleans, there is at least a consistency between those two operators, even though it's consistently weird. There's definitely a strong case for making them match +=1 and -=1 though. Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
On 17/02/2020 15:55, Paul M. Jones wrote: I apologize in advance for the length of this email. I hate reading walls-of-text, but the answers are necessarily long. I have tried to break it up into bullets where possible for easier reading. No, thank you for taking the time to respond. I've cherry-picked rearranged the quotes in this reply a bit so I can try not to repeat myself too much; let me know if I've taken your words too far out of context. ...it is likewise valid to say that AdoDB "took functionality that was scattered across a dozen different vendor-specific extensions with different naming and calling conventions, and centralised it into one more-or-less consistent interface." So did PEAR DB, Metabase, MDB, and so on. PDO did it as an extension, instead of in userland, but the goals and outcomes noted were identical. That's a fair point, everything PDO does could be and has been done in userland. There is one thing that couldn't be done outside of an extension, though, which is that PDO doesn't rely on the legacy extensions, it (in theory at least) replaces them. What I think is slightly more relevant, is that PDO makes writing wrappers like ADODB easier, because it contains non-trivial functionality that those wrappers would otherwise have to write. I don't *expect* anything from existing published library authors ... I always thought of the "intended audience" as the much the same as for any RFC I think perhaps my choice of words has caused a bit of confusion. Perhaps "hope" would have been better than "expect", and "use cases" better than "intended audience". I was trying to draw out two pieces of information: - What's the sales pitch - what do YOU think is great about these classes? - When working out the details, what code should we be picturing using the new classes? I wasn't around when PDO was proposed, but an imaginary "sales pitch" might have gone something like this: - Developers should be able to implement multiple database systems without learning the quirks of each vendor's extension - Library authors shouldn't need to implement the basic functionality of every driver from scratch when the vendor could do it for them - Vendors shouldn't need to decide which API to follow, when we can normalise everything internally - We can offer different result formats and error-handling models out of the box ...and so on - some [library authors] may find their own work so close to this extension that they migrate over to it entirely. So, there is at least some hope that this will entirely replace some people's existing libraries, even if it doesn't replace the more powerful ones like HttpFoundation. That's probably reasonable. (Note that I've been thinking of "library" fairly loosely - a single class used in a completely private monolithic repo, but which is written to be generic functionality, has much the same role as a public composer package in this case.) For myself, and as noted by Jan Schneider and others, those benefits center around... This is what I was looking for. Sell it to me! :) ...a built-in OO-ish request/response object set... "OO-ish" is a wise choice of words here. One of the reasons I'm not terribly keen on this proposal - particularly the request half - is that I'm a bit of an OO purist. By that I mean that I prefer objects that have a strong responsibility, and encapsulate useful behaviour, rather than just spitting out what went in. The response part of the proposal is closer to "real" OO, IMO, because it includes behaviour like manipulating individual headers and cookies. The lack of behaviour also makes it less useful to people writing their own request and response objects: if I have a copy of $_POST and want to put it in my own object property, why would I first pass it to a ServerRequest object, and then get it straight back out again, if the object isn't helping me do anything with that data? That said, I know some people are happy with OO-ish code, some even to the extent of preferring stdClass to an array. So it's not unreasonable to say that this will appeal to developers who are less puritanical about objects than me. ...that does pretty much just what PHP itself already does... As you say elsewhere, this is useful for helping people migrate to it. The flipside of that is that it ties us into past decisions, rather than evaluating whether those decisions are still what we want. The approach in providing both $files and $uploads arrays is a good compromise - provide the new better way, but also an easy-to-migrate way. I'd love to see them named more distinctly, though, maybe even calling one of them "legacy". I'd probably also make them methods so that the data can be stored once (in the new format) and re-formatted on demand (again, objects as behaviour rather than data). ...easing their transition away from global state This I find less c
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> On Feb 18, 2020, at 08:10, Côme Chilliet > wrote: > > to me that means we also need an addContent method. I can see why we'd think that; it's symmetrical, if nothing else. Even so, none of the researched implementations have a method like that. As far as I can recall, they call have setContent() and getContent() equivalents, but no addContent() equivalent. They all work much like you point out here ... > Otherwise people will have to carry a global $content along side $response, > or use setContent(getContent().$additionalContent). ... although usually it's not a global $content. Instead, the $content is built up from a template or other subsystem of some sort, and then assigned to the response when complete. For example: $content = $template->render(); $response->setContent($content); So, I am reluctant to add something that no other implementations, across many years and many authors, have actually found a need for. Any further thoughts on this? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Le mardi 18 février 2020, 07:33:37 CET Paul M. Jones a écrit : > ... the output would be "b\n". As you say, setContent() replaces whatever > content is already in the ServerResponse. While the comparison for a single > echo is accurate, the comparison for multiple echoes would be: > > $content = "a\n"; > $content .= "b\n"; > $response->setContent($content); > $responseSender->send($content); > > Does that help to clarify? Yes, but to me that means we also need an addContent method. Otherwise people will have to carry a global $content along side $response, or use setContent(getContent().$additionalContent). -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow null variables to be decremented
On Sat, Feb 15, 2020 at 6:44 PM Rowan Tommins wrote: > Hi all, > > There is currently an odd inconsistency when using the decrement > operator on a null variable: > > $a = null; $a=$a+1; // int(1) > $a = null; $a+=1; // int(1) > $a = null; ++$a; // int(1) > > $a = null; $a=$a-1; // int(-1) > $a = null; $a-=1; // int(-1) > $a = null; --$a; // null > > I would like to propose changing this behaviour for PHP 8, so that --$a > would give int(-1), as I believe it is simply a long-standing bug. > > > This has been raised as a bug at least three times [1][2][3] but closed > as documented behaviour / too much of a BC break. It is documented in > the manual, but with no explanation of why it should work that way. [4] > > I would be interested in any explanations of why it might be intended > behaviour, or ways in which people might be relying on the current > behaviour. > > A proposal to change the behaviour was included in a wider RFC about > standardising increment and decrement behaviour, but it never got beyond > draft status. [5] I would prefer not to reopen that wider debate, but > focus on this single issue. > > As far as I can see, the change would be to add a "case IS_NULL" branch > to decrement_function in zend_operators.c to match the one in > increment_function. [6] > > > I will happily write up an RFC to formalise this, but wanted to gather > people's immediate thoughts first. > Principally in favor of this change, I do think that ++ and -- should behave consistently if nothing else. We might want to consider giving the same treatment to false/true as well, which should be interpreted as 0/1. That is $foo++ / $foo-- should behave the same ways as $foo+=1, $foo-=1 for null, true, false. It seems odd to single out only "null" here. Additionally I would suggest a notice when trying to increment arrays, resources and objects, rather than just silently doing nothing. As long as it's just a notice, this should have minimal BC implications. Nikita
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Côme,
> On Feb 18, 2020, at 03:24, Côme Chilliet
> wrote:
>
> Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit :
>
>> Yeah, naming is one of the hard problems. I considered $query as an
>> alternative property name for $get, but in the end, the `$_GET => $get`
>> symmetry was too great to ignore. If others here feel that $query is a
>> better name for `$_GET` than $get, I will submit to consensus on that point.
>
> query is definitely better than get.
Excellent.
> Regarding post, I’m fine with body, parsedBody and input.
>
> I get the idea of input to mimic php://input, but if I understand things
> correctly, php://input is raw body, while $request->post is parsed body, so
> naming them alike might actually cause confusion?
Might, might not. I don't think there is any "good" name here, only names that
are less-bad than others.
> I still do not understand this.
> echo adds content to the response, it does not replace it.
> So the equivalent function should be $response->addContent.
>
> I would expect $response->setContent to replace the content.
Ah, I see what you are getting at now ...
> Can you explicit behavior for this:
>
> $response->setContent("a\n");
> $response->setContent("b\n");
> $responseSender->send($response);
>
> Compared to
>
> echo "a\n";
> echo "b\n";
... the output would be "b\n". As you say, setContent() replaces whatever
content is already in the ServerResponse. While the comparison for a single
echo is accurate, the comparison for multiple echoes would be:
$content = "a\n";
$content .= "b\n";
$response->setContent($content);
$responseSender->send($content);
Does that help to clarify?
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make var_dump() use serialize_precision
Am 18.02.20 um 12:20 schrieb Nikita Popov: > Hi internals, > > https://github.com/php/php-src/pull/5172 changes var_dump() to use > serialize_precision instead of precision to dump floating-point numbers. > > To recap: serialize_precision defaults to -1, which will print exactly as > many floating-point digits as are needed to represent the number > accurately. precision defaults to 14, which will print a shorter but > potentially inaccurate float representation. > > The motivation here is that var_dump() is debugging functionality and > should print values as accurately as possible. The single most common bug > report we receive is some kind of variation on: > > $sum = 0.1 + 0.2; > var_dump($sum); // float(0.3) > var_dump($sum == 0.3); // bool(false) WTF??? > > After this change, this would instead be: > > $sum = 0.1 + 0.2; > var_dump($sum); // float(0.30004) > var_dump($sum == 0.3); // bool(false) Makes sense... > > I have little hope that developers will suddenly start understanding > floating-point numbers, but at least this should reduce the amount of > confusion. > > Does anyone see an issue with doing this change? You mean apart from people now filing bugs how var_dump() can output such a nonsensical number from such an easy equation? And that it again shows that PHP is not a real programming language (unlike JavaScript) and should never be used at all? Nope ;-) Cheers Andreas PS: I'd absolutely appreciate the change!!! -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +-+ | http://hei.gl/root-ca | +-+ signature.asc Description: OpenPGP digital signature
[PHP-DEV] Make var_dump() use serialize_precision
Hi internals, https://github.com/php/php-src/pull/5172 changes var_dump() to use serialize_precision instead of precision to dump floating-point numbers. To recap: serialize_precision defaults to -1, which will print exactly as many floating-point digits as are needed to represent the number accurately. precision defaults to 14, which will print a shorter but potentially inaccurate float representation. The motivation here is that var_dump() is debugging functionality and should print values as accurately as possible. The single most common bug report we receive is some kind of variation on: $sum = 0.1 + 0.2; var_dump($sum); // float(0.3) var_dump($sum == 0.3); // bool(false) WTF??? After this change, this would instead be: $sum = 0.1 + 0.2; var_dump($sum); // float(0.30004) var_dump($sum == 0.3); // bool(false) Makes sense... I have little hope that developers will suddenly start understanding floating-point numbers, but at least this should reduce the amount of confusion. Does anyone see an issue with doing this change? Regards, Nikita
[PHP-DEV] Bad quality of turkish translation
hello, due to the very bad quality and majority of missing chapters and of the neglected turkish translation of php documentation, I would like to acquire the admin management of the doc...@lists.php.net Thanks, Midori Kocak
[PHP-DEV] [RFC] Language evolution (overview proposal)
Hi internals, I'd like to present an overview proposal on how to deal with opt-in backwards-incompatible changes: https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md This proposal is intended as a discussion starting point, so we can decide on the general direction we want to pursue. If we have a rough consensus, then a second proposal could sort out the details of a particular approach. A pull request is available to leave inline comments: https://github.com/php/php-rfcs/pull/2 Regards, Nikita
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit :
> Yeah, naming is one of the hard problems. I considered $query as an
> alternative property name for $get, but in the end, the `$_GET => $get`
> symmetry was too great to ignore. If others here feel that $query is a better
> name for `$_GET` than $get, I will submit to consensus on that point.
query is definitely better than get.
Regarding post, I’m fine with body, parsedBody and input.
I get the idea of input to mimic php://input, but if I understand things
correctly, php://input is raw body, while $request->post is parsed body, so
naming them alike might actually cause confusion?
> > Given 'echo $content; => $response->setContent($content);', shouldn't
> > this rather be something like `addContent()`?
>
> That looks like poor describing on my part in the RFC. It is more true to say
> that these are equivalent:
>
> echo $content;
>
> // =>
>
> $response->setContent($content);
> $responseSender->send($response);
>
> I will try to make that more apparent in the RFC.
I still do not understand this.
echo adds content to the response, it does not replace it.
So the equivalent function should be $response->addContent.
I would expect $response->setContent to replace the content.
Can you explicit behavior for this:
$response->setContent("a\n");
$response->setContent("b\n");
$responseSender->send($response);
Compared to
echo "a\n";
echo "b\n";
--
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
