Bug #18236 Updated: EXACT HTTP POST data access

From: Date: Tue, 09 Jul 2002 13:59:44 +0000
Subject: Bug #18236 Updated: EXACT HTTP POST data access
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-13604@lists.php.net to get a copy of this message
ID: 18236 Updated by: sesser@php.net Reported By: foobardotcom@poczta.onet.pl Status: Open Bug Type: Feature/Change Request Operating System: Linux cyberhq 2.4.19-pre6 #2 SMP PHP Version: 4.2.1 New Comment: here is the url: http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2002-07-09 07:07:53] markonen@php.net Right. We need a standards-compliant, alternative syntax for the current array[] feature. The magical convert-all- multiply-defined-vars-to-an-array stuff isn't going to happen. There are just too many issues to deal with on that road. ------------------------------------------------------------------------ [2002-07-09 06:53:25] m.ford@lmu.ac.uk The problem here is not really needing to type the extra two characters, but that the resulting name/id is *not* *in* *conformance* *with* *HTML4.0*, which states that: > ID and NAME tokens must begin with a letter ([A-Za-z]) > and may be followed by any number of letters, digits > ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), > and periods ("."). [http://www.w3.org/TR/html401/types.html#h-6.2] So we either have to write non-conformant HTML (not even permitted at some sites!), or program round it (e.g. by naming form elements foo_1, foo_2... and then searching for them in a loop), which is inefficient. Besides this one, bugs #10502, #15498 and #16195 are all OPEN feature requests for the "automatically convert to array" functionality, so there is a fair level of demand for it. Besides, a language that claims to be "especially suited for Web development" [http://www.php.net/] should not actually prevent the writing of standards-conformant Web pages. I wish I had the spare time to investigate the PHP sources and write a patch for this myself, but I just don't. (I only just find time to read the lists most days, but sometimes I even have to dump 100s of messages unread!) Cheers! ------------------------------------------------------------------------ [2002-07-09 05:00:29] hholzgra@php.net maybe $HTTP_RAW_POST_DATA is what you are looking for? btw: please define "behave correct on select multiple" what is so bad about specifying that you are going to fill an array? the alternative would be to create arrays if multiple values are set while single selections would still become simple strings as there is no way for PHP to know that it was generated from a <select multiple> so it's just a tradeof: having to type two more characters as element name or taking care that both string and array inputs are supported in the form processing code our approach is obviously the first one ------------------------------------------------------------------------ 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

« previous php.bugs (#13604) next »