Konstantin,
On 2/17/21 10:35, Konstantin Kolinko wrote:
ср, 17 февр. 2021 г. в 12:09, Mark Thomas <ma...@apache.org>:
On 16/02/2021 14:58, Christopher Schultz wrote:
All,
I'm sorry for using users@ as my own personal Google but I'm sure
someone knows this off the top of their head and can save me a lot of
reading.
I'm wondering about which specs mention how to handle URL parameters
(and POST parameters, for that matter) in terms of ordering. For
example, if I have a URL like:
https://example.com/context/resource?a=1&b=2&c=3&a=6
(Note that I have "a" in there twice)
If I call request.getParameterNames(), is there a predictable order in
which those parameters will be handed back? I'd love to hear that not
only are they returned in "URL order" (that is, the left-most parameter
is the first returned in that enumeration) in Tomcat, but either the
servlet spec, the CGI spec, or some other spec dictates that order
explicitly.
Yes, they will be in that order. (See ApplicationHttpRequest.parameters,
ParameterMap.delgatedMap and LinkedHashMap
The order isn't explicitly defined in any specification I am aware of.
However, the Servlet spec does state (3.1) that query string parameters
should be presented before parameters parsed form the request body.
1. When there are multiple values, the order of values is preserved.
Java Servlet 4.0 spec has an example in its text that shows how the
order of values is preserved (chapter 3.1 "HTTP Protocol Parameters"):
<quote>Data from the query string and the post body are aggregated
into the request parameter set. Query string data is presented before
post body data. For example, if a request is made with a query string
of a=hello and a post body of a=goodbye&a=world, the resulting
parameter set would be ordered a=(hello, goodbye, world)</quote>
Yes, that's the section Mark was referencing. While the example may be
instructive, it is not explicit. I'm just requesting explicit language
in the spec for that assumption.
2. Original specification for url-encoded parameters is not HTTP, but
HTML specification. The place where I first saw it many years ago was
here:
https://tools.ietf.org/html/rfc1866#section-8.2.1
HTML 2.0 spec
The fields are listed in the order they appear in the document
+1
Personally, I would not rely on the order of names provided by
getParameterNames(), as it would be surprising for a client if
processing of a request depends on the order of parameter names. In
the same way as whether reordering of input fields on a web form could
break its processing.
I disagree: both HTML and HTTP make it clear that form-data ordering is
important and should be preserved. Given the importance placed on that
ordering, I think that same importance and reliable ordering should be
extended explicitly into the Servlet Specification explicitly.
In my use-case, I have a series of questions being presented on the
screen. When I receive the answers to those questions, I'd like to be
able to rely on the form-data ordering to know which questions were
presented first and which ones later when they are all on the same form.
Without being able to rely on form-data ordering, the only way to "know"
which question was asked first, second, etc. would be to either put a
hidden form element on the page describing the question-order (back to
the server) or to have individual hidden elements for each question
specifying the order. Something like this:
<input type="hidden" name="question_3762_order" value="1" />
<input type="hidden" name="question_213_order" value="2" />
...
If the ordering can be reliable, less data needs to be exchanged.
I have presented a justification for this in the issue filed for the
Servlet API[1] and I'm happy to hear any critique you may have of that
justification.
For emphasis:
Personally, I would not rely on the order of names provided by
getParameterNames()
It is precisely because of the ambiguity of the specification that I am
requesting clarification and, further, explicit definitive required
behavior of the Servlet Specification such that application developers
*can* rely on that ordering.
-chris
[1] https://github.com/eclipse-ee4j/servlet-api/issues/393
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
