Bug #18236 Updated: EXACT HTTP POST data access

ID: 18236 Updated by: foobardotcom@poczta.onet.pl Reported By: foobardotcom@poczta.onet.pl -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Linux cyberhq 2.4.19-pre6 #2 SMP PHP Version: 4.2.1 New Comment: > It is not possible for PHP to magically create Arrays. You mispelled: not "magically", but "logically" :) > It will a) break scripts, because they will not expect > an Array. Hey, did you read this below? > > backwards compatibility alone would justify this > (...) IMO PHPDevTeam should give NEW way to access > variables from request in PHP, that will give "backwards > compatibility" (of course; recent access methods will be > accessible all the time), but with new functionality. I wrote this after taking backwards compatibility into consideration. So, let's give an example: someone who wrote script before, and this script was using $_GET["id"] will have ALWAYS LAST VALUE, like in old parser - and everything will be *exactly* backwards compatibile in this way of accessing values from request. The new-way-parsed query strings will be placed for example in $_G superglobal array. And likewise - make $_POST array deprecated, and bring out new array - for example $_P. Aha! And old method - $_GET should be deprecated like today arrays $HTTP_***_VARS are, so if someone will turn on all errors (error_reporting(E_ALL)), then notices about deprecated calls should be generated. > It will b) break scripts, because some versions of IE > think its better to send all variables 2 times in some > situations. Excuse me, what are You talking about? I didn't heard about anything like this, please, give me some link, example or some information about that issues! But... there are walkarounds for client-side bugs, PHP-programmers can foresee their existence and apply possible the best patches. In spite of fact that the client-side bugs exist, IMO that's not the reason of not-changing PHP in the proper trend. On the other hand, PHPDevTeam shouldn't adapt PHP language to any other (in this case client-side) bugs!!! Previous Comments: ------------------------------------------------------------------------ [2002-07-13 05:30:10] sesser@php.net It is not possible for PHP to magically create Arrays. It will a) break scripts, because they will not expect an Array. It will b) break scripts, because some versions of IE think its better to send all variables 2 times in some situations. and btw.... even if your HTTP sends a 404 or whatever reply, it has still to discard the whole posted block. And as long the server has no 10 GBit connection this will be the bottleneck, not the parsing. ------------------------------------------------------------------------ [2002-07-13 03:01:45] foobardotcom@poczta.onet.pl Let's say that's "enough good argument" to change status of this bug to "bogus". This argument tells something about whole PHP team, in fact - about discarding real arguments. I repent of learning PHP... and, as everything seems even Zend Engine 2.0 will not help on fact, that team isn't able to discuss and think... Once again, excuse my english... maybe the last one :-S ------------------------------------------------------------------------ [2002-07-13 02:35:17] sniper@php.net You obviously shouldn't be using PHP.. ------------------------------------------------------------------------ [2002-07-13 02:10:30] foobardotcom@poczta.onet.pl > > the advantage of PHP is exactly that you *don't* have > > to parse query strings or post data yourself > If some feature is *forced* and *auto-off*, that isn't an > advantage. excuse me, I mean "auto-on", not "auto-off"... ------------------------------------------------------------------------ [2002-07-13 02:04:44] foobardotcom@poczta.onet.pl > we can talk about preserving POST DATA in all cases > but parameter parsing behaviour will definetly stay > as it is why? (see below...) > backwards compatibility alone would justify this Hmmm... so, if something was bad before, it must stay for backwards compatibility?! That's funny ;) IMO PHPDevTeam should give NEW way to access variables from request in PHP, that will give "backwards compatibility" (of course; recent access methods will be accessible all the time), but with new functionality. > there is nothing magic about the parameter parser, > it assigns values to variables, and if a query string > has multiple assignments to the same parameter name then > the last one wins, thats it Anyone can deduce, that IF BROWSER SENDS MULTIPLE VALUES WITH THE SAME NAME IT MAY MEAN THAT ALL OF THESE VALUES HAS TO BE ACCESSIBLE FOR THE SERVER-SIDE PROGRAM! There's nothing logical in your opinion. But I hope, fighting the windmills (as your conviction about "last-value = winner") may bring the new quality to PHP: > *if* browsers would tell what field type input came from > we could talk (...), but fact is that they don't Standards doesn't say about TYPES in HTTP query string. Forgive me my inquirity, but everything seems, that as I wrote about it above - if BROWSER SEND MULTIPLE VALUES WITH THE SAME NAME (...), uh, maybe this (http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/asp/vbob4fl9.htm) will help You to understand... I know - maybe learning PHP developer based on ASP example isn't so happy idea but slowly, I'm loosing faith in PHP... > and making everything an array is simply not an option look above. > the advantage of PHP is exactly that you *don't* have > to parse query strings or post data yourself If some feature is *forced* and *auto-off*, that isn't an advantage. Let's look on this case from other side: if I have a script, that is awaiting for ID parameter in query string, and someone will POST a file to it... what do you think about performance of that operation? Sorry, I found a better example: it's not a file, but a lot of parameters and values - let's say 1,5MB! IMO script shouldn't parse it automatically. IT DOES BECAUSE OF THAT "ADVANTAGE" DEPENDS ON AUTO-ACCEPT POLICY! There's a big problem - PHP script makes all values "accessible" just at start. Apache does handle request, because it is HTTP server, so performance cost is well-founded, but PHP should give "400 Bad Request" if there's something not-needed that is passed to it, whether it is file, post data or just a query string. > hey, we even transparently parse different post encodings > for you, like multipart/form-data for file uploads or > application/vnd.fdf for form data sent by acrobat reader > (and you can register even more POST data handlers based > on Content-Types on the C extension levels) WOW! And, in Your opinion that's an advantage???!!! IMVHO it's a BUG because there are lot of performance costs - OK, HTTP server has the file already in RAM, but WHY PHP DOES PARSE AND CALCULATE IT AUTOMATICALLY?! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18236 -- Edit this bug report at http://bugs.php.net/?id=18236&edit=1