get request parameters are not in order

J

John

Here's the code fragment to enumerate the request parameters list, but
the order
is not the same as in the query string.

http://localhost:9999/projWeb/EStoreServlet?a=1&b=2&c=3&d=4

==========================
Code
==========================
for (Enumeration e = req.getParameterNames(); e.hasMoreElements();)
{ Object obj = e.nextElement();
String key = obj.toString();
String value = req.getParameter(key);
out.println(key + "," + value + "<br>");
}

==========================
output
===========================
b,2
a,1
sub,Logon
d,4
c,3

any ideas?

please advise. thanks!!
John.
 
M

Matt Humphrey

John said:
Here's the code fragment to enumerate the request parameters list, but
the order
is not the same as in the query string.

http://localhost:9999/projWeb/EStoreServlet?a=1&b=2&c=3&d=4

<snip demonstration code>

The parameters are name-value pairs without any presumption of order. They
are probably stored in a HashMap and the enumeration order depends on the
hashing. I tried your code and the parameters came back in mixed order for
JBoss 4.0.2.

I searched through various javadocs and could not find anything that says
the parameters should be retrievable in their original order. If your
design relies on parameter order, something is going to have to change.
Also, I don't think there's any guarantee that forms or other external
sources will put the parameters in the textual order given, or that URL
transforms (URL rewriting) will preserve the order.

If you can't change the design, you can retrieve the original query string
(getQueryString) and pick off the parameters yourself. There are some
libraries to do this, although I don't know their names. Especially for POST
requests, reading the body as a stream may interfere with the ability to
read the names in order.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/
 
A

Andy Flowers

John said:
Here's the code fragment to enumerate the request parameters list, but
the order
is not the same as in the query string.
any ideas?

please advise. thanks!!
John.

The order is not guaranteed and can be affected by the the sending client and
the receiving server.

Why do you need to read the parameters in a specific order ?

If you need to do that then you will have to do the ordering yourself, possibly
by appending a number to the parameter name to give the order,

i.e.

http://localhost:9999/projWeb/EStoreServlet?param1=1&param2=2&param3=3&param4=4

and then parsing this using the know prefix 'param'.
 
O

Owen Jacobson

The order is not guaranteed and can be affected by the the sending client and
the receiving server.

No, only by the receiving server. According to the HTTP and URL/URI
specifications the URLs

http://www.example.com/someapp/servlet?a=foo&b=bar
and
http://www.example.com/someapp/servlet?b=bar&a=foo

are distinct resources. The Java servlet specification allows the
servlet container to reorder request parameters because in practice those
are more often the same resource with two names than two distinct
resources, and storing the parsed parameters in a hashmap is far faster
than seeking through them in order.

IMO parameters should probably be provided in a LinkedMap or LinkedHashMap
stored in URL order, because there are some useful idioms based on
multiple occurrences of the same parameter, but I haven't written a
servlet container or plugin, so my opinion's worth the electrons to print
it and not a bit more.

Owen
 
H

Henry Townsend

Owen said:
IMO parameters should probably be provided in a LinkedMap or LinkedHashMap
stored in URL order, because there are some useful idioms based on
multiple occurrences of the same parameter, but I haven't written a
servlet container or plugin, so my opinion's worth the electrons to print
it and not a bit more.

At least in Tomcat my experience has been that repeated parameters are
always returned in order. I.e. using getParametervalues() with:

http://www.example.com/someapp/servlet?a=X&a=Y&x=Z

returns an array in the "natural" order. I agree this is a useful idiom
and could be a solution for the OP, but I don't see it guaranteed
anywhere in the spec.

HT
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top