Nice! That's the same way PHP does it, but I didn't know it worked on Railo as well.

This:
page.cfm?a[]=1&a[]=2&a[]=3,4

Is equivalent to:
a = Array( '1' , '2' , '3,4' )

Works for form variables also.

As well as capturing comma values safely, this can also be used to avoid manually building an array from sequentially named form fields.

My point was that with CFML's processing, you can't determine whether the example request had three instance of the 'a' parameter (one of which contains a comma) or four instances of the 'a' parameter, none of which contain commas. Or for that matter, a single instance of 'a' containing three commas. With the request parameter method you CAN make that distinction. ServletRequest's getParameter() and getParameterValues() correspond exactly to QueryDict's getItem() and getList().

The point is that CFML's processing destroys information within the CFML environment. You usually don't care about it, but still destroys info. When it DOES matter you can still get back that information from the underlying Servlet container.

But, for security sake, they should be treated equivalently. Their input should be equally untrusted. I don't see a reason to differentiate for functionality or for security.

For example in Django, you would get QueryDict object back for all parameters. If 'a' has multiple items in the query string as in your example, calling queryDict.getItem('a') returns only the *last* item (not all items). So you still have to be smart enough to call queryDict.getList('a') to get all the items. (Side step: Lists in Python are like CFML arrays not a string list.) And I wouldn't call getList() all the time to "solve" the issue because that method guarantees a list be returned and I wouldn't want to work with a list for each parameter.

You still have to think that the parameter has multiple values in Django and call the right methods otherwise you just get the last value in the items (which could be disastrous) . The only difference is CFML gives you them all up front instead of having to deduce if you need to call getList() like in Django for all the items. To me, six of one / half dozen of another. Same result because you have to know if you should be expecting multiple items.

Can you provide a concrete example of why I'd care? Or more specifically, why I'd ever want to treat them differently? GET is certainly easier to maliciously request than POST, but that's a request method distinction, not a parameter source distinction. I.e. I only allow POST for certain URLs, GET for certain other ones, and both for a third set. But once I'm inside a request, the parameters are just parameters.

For example, within an FB3Lite app where your form actions all start with "do", stick this in the onRequestStart fuseaction:

<cfif left(attributes.originalFuseaction, 2) EQ "do" AND cgi.request_method NEQ "POST">
  <cfthrow type="AccessDenied.InvalidRequestMethod" />
</cfif>