It's indeed not explicitly definied in the Servlet spec, but at least the HTML forms spec definies it explicitly in the application/x-www-form-urlencoded section:
2.The control names/values are listed in the order they appear in the document.
So, that part is safe. Now the servletcontainer, most logically a decent and efficient implementation would process the HTTP input stream immediately as it comes in, so the parameters would be processed in the order as they appear in the request URI (GET) or request body (POST). Collecting them in a String[]
is the most straightforward choice as it is also used as-is in the Servlet API, so I really don't see any reason to collect it in a HashSet
like structure first, or do a Collections#shuffle()
or whatever and then convert it to String[]
afterwards.
I can at least tell from experience, Tomcat does it the right way, so all major containers/appservers which are built on top of Tomcat/Catalina (IBM Websphere, JBoss AS, Sun Glassfish, etc) will also behave so. I only don't have hands on experience with Weblogic, but I would be surprised if it processes it differently (read: less efficiently).
Only the ordering of the parameter names is not guaranteed, logically because it's backed by a HashMap
.
Summarized: the parameters are collected in a HashMap<String, String[]>
. The names are quaranteed not ordered due to the nature of the HashMap
. The values (one parameter name can have multiple values, e.g. foo=bar1&foo=bar2&foo=bar3
) are in turn however ordered due to the nature of String[]
, although this is not explicitly specified in the Servlet API.
To be on the safe side, you'd like to use a different approach, e.g.
foos=3&foo[0]=bar1&foo[1]=bar2&foo[2]=bar3
with
int foos = Integer.valueOf(request.getParameter("foos"));
for (int i = 0; i < foos; i++) {
int foo = Integer.valueOf(request.getParameter("foo[" + i + "]"));
}