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: HTTP_RAW_POST_DATA is set only when ***file*** is uploaded or somthing like that. There is no HTTP_RAW_POST_DATA if method is POST and enctype is standard - "application/x-www-form-urlencoded". I'm looking for query string (without `?' at the beginning) that is passed after HTTP request header when POST method is used. > btw: please define "behave correct on select multiple" I mean PHP should "parse" select multiple results correctly, because now it isn't, for example: GET /foo.php?bar=dot&bar=com HTTP/1.0 In PHP sciript, there's only last value: $_GET["bar"] is "com". $_GET should look as below: array( "bar" => array( 0 => "dot", 1 => "com" ) ); ...IMO of course. I tought about creating array from EVERY VARIABLE that is passed, so request: GET /foo.php?a=b HTTP/1.0 should (I say again - IMO) give $_GET array looking like that: array( "a" => array( 0 => "b" ) ); ...people who like "easy programming" will use some custom functions to make access more simple, the functions like that: function makeEasierAccessToRequestArray($arr) { foreach($arr as $key => $arrOfVals) { if (sizeof($arrOfVals) === 1) { $arr[$key] = $arrOfVals[0]; } } return $arr; } $GLOBALS["_MYGET"] = makeEasierAccessToRequestArray($_GET); Next thing: > After (...) it looks like the only suitable alternative > syntax would be > array-key- = value > or > array_key_ = value > i.e. substituting a hyphen or an underscore for the > square brackets. (...) Why PHP developers are so inclined to create MAGIC BEHAVIOURS and PHP-ONLY EXCEPTIONS (for example MAX_FILE_SIZE or arr[] multiple values)? I'm against MAGIC RULES so if someone will tell me, that he has created forms making output like this: GET /foo.php?arr[0][0]=foo&arr[0][1]=bar&arr[1][0]=dot&arr[1][1]=com HTTP/1.0 and he like to use arrays obtained from (*fucked*, being plainspoken) query-string parser from PHP, WHY HE DON'T CREATE HIS OWN LIBRARY, THAT CAN PARSE QUERY STRING AS ABOVE FOR HIS EASY USE? I see no problem: <?php function escaper($regs) { return '$GLOBALS["GET"]["' . addslashes($regs[1]) . '"] ' . $regs[2] . ' "' . addslashes($regs[3]) . '";'; } eval(preg_replace_callback("/([^=]+)(=)([^&]*)/", "escaper", $QUERY_STRING)); // it works like that: query string == "a=b", // then it evals code: $GLOBALS["GET"]["a"] = "b"; // it use escaped vals, so there's no possibility // to call function within query string or to make // parse error, for example specyfying query string // like that: `"=foo', becuase code generated then // will look like that: $GLOBALS["GET"]["\""] = "foo"; ?> Yes, and we're in the same place. WHAT WITH POST'ED VALS?! EXACTLY! If $_SERVER["SERVER_METHOD"] will be "POST" there will be no possibility to parse it manually, will the best will in the world! Why? Because there is no possibility to access HTTP-Request data RAWLY! IMHO language should be clean and logical, without ANY EXCEPTIONS AND MAGIC BEHAVIOURS. What PHP programmer will do, it's his business, not EVERYONE WHO WANT TO USE PHP. So, after my long lecture I await, there SHOULD NOT be alternative to syntax to `arr[]', because it would be MAGIC BEHAVIOUR. If someone will send request: GET /foo.php?array-key-=value&multi=1&multi=2 HTTP/1.0 $_GET should look like that: array( "array-key-" => "value", "multi" => array( 0 => "1", 1 => "2" ) ); I propose this way instead of creating every value multiple (I wrote about it before), becuase THIS LAST METHOD will not collide with every PHP-programmer habits. Previous Comments: ------------------------------------------------------------------------ [2002-07-09 10:19:02] m.ford@lmu.ac.uk Damn, you're right! That'll teach me to read specs more closely (and not to believe everything everyone tells me!!). OK, forget this one for me -- but how about closing or won't-fix-ing all those open feature requests? Cheers and sorry for the bother! ------------------------------------------------------------------------ [2002-07-09 10:02:58] derick@php.net Or with XHTML 1.1: http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_extformsmodule NAME = CDATA here too ------------------------------------------------------------------------ [2002-07-09 09:59:44] sesser@php.net here is the url: http://www.w3.org/TR/html401/interact/forms.html#h-17.4 ------------------------------------------------------------------------ [2002-07-09 09:57:00] sesser@php.net The claim that [] violates html 4.0 is simply wrong. The html 4.0 specification clearly states that the name attribute for the input tag is of the type CDATA and not of type ID/NAME. ------------------------------------------------------------------------ [2002-07-09 07:42:15] markonen@php.net After a brief debate on #php.bugs, it looks like the only suitable alternative syntax would be array-key- = value or array_key_ = value i.e. substituting a hyphen or an underscore for the square brackets. This way we'd be compatible with the "Namespaces in XML" recommendation (at http://www.w3.org/TR/REC-xml- names/) which gives meaning to colons in name tokens. The place to implement this would be php_register_variable_ex() in main/php_variables.c. There will be a small performance penalty. ------------------------------------------------------------------------ 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