Jcobban, it sounds as if you've changed your argument. [EDIT: See edit below] If I am misunderstanding you, please clarify. I thought you were originally displeased by the use of [] bracket characters in the value of a select element's name attribute.
jcobban wrote:However if I code the HTML as:
Code: Select all
<select name='fruit[]' multiple='multiple'>
<option value='A'>Apple</option>
<option value='B'>Banana</option>
<option value='C'>Cherry</option>
</select>
then the multiple values are passed to the web server as "...?fruit[]=A&fruit[]=B&fruit[]=C". In the PHP script the value of $_GET['fruit'] is the array {"A", "B", "C"}.
But later you said you're not concerned about the characters used but the case-sensitivity of it?
Weirdan wrote:Where PHP goes somewhat against the spec is not the set of characters used in name attribute, but the fact that it treats incoming parameters as case sensitive whereas user agents should treat form field names in case-insensitive manner
[EDIT: I accidentally quoted Weirdan here and mistreated his statement as if it were said by jcobban. Hence my confusion.]
As far as the use of [] bracket characters, as has already been stated, the piece of the
HTML spec you quoted about the ID and NAME tokens does not apply to your argument; it is erroneous. From the
HTML 4 Document Type Definition:
http://www.w3.org/TR/html401/sgml/dtd.html wrote:[text]<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector -->
<!ATTLIST SELECT
%attrs; -- %coreattrs, %i18n, %events --
name CDATA #IMPLIED -- field name --
size NUMBER #IMPLIED -- rows visible --
multiple (multiple) #IMPLIED -- default is single selection --
disabled (disabled) #IMPLIED -- unavailable in this context --
tabindex NUMBER #IMPLIED -- position in tabbing order --
onfocus %Script; #IMPLIED -- the element got the focus --
onblur %Script; #IMPLIED -- the element lost the focus --
onchange %Script; #IMPLIED -- the element value was changed --
%reserved; -- reserved for possible future use --
>[/text]
Clearly, the name attribute of a select holds values of type CDATA, not NAME.
Regarding the case-sensitivity issue you raise, [EDIT: Actually Weirdan. See above.] I would argue that PHP does not need to implement any markup language spec at all (HTML 4, XHTML 1.1, etc.); that's a different layer. The server-side (e.g., Apache/PHP) is responding to HTTP requests. HTTP is defined in other specifications which are not tightly coupled to HTML or any specific markup language. I couldn't find any relevant specs or RFCs that describe whether query string or application/x-www-form-urlencoded name=value pairs should be interpreted in a case-sensitive manner or not. I could be wrong on that.
If you don't like how PHP does this, why don't you refrain from using the $_GET superglobal and just parse the $_SERVER['QUERY_STRING'] value manually? (Or read the php://input stream for raw POST data.) This way you can interpret duplicate parameters and letter case however you wish! Problem solved.
Lastly, you should read about
web application parameter pollution to learn just how jumbled the interpretation of request parameters across various back-end platforms really is. IMHO PHP's behavior is very reasonable compared to other platforms.