On 17/02/2021 14:03, Christopher Schultz wrote: > Mark, > > On 2/17/21 04:08, Mark Thomas wrote: >> 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. >> There are several ways to implement that but it is likely that an >> implementation will simply maintain insertion order for keys and values >> (where there are multiple values for the same key) in a single >> collection. At least, Tomcat does this. >> >>> Similarly, if I use request.getParameterMap and than iterate through the >>> keys or Map.Entry objects in it, does that behave predictably as well? >> >> Same answer as above. >> >>> I have a situation where both URL parameters and POST parameters being >>> in URL-order (or document-order for POST parameters) would be highly >>> convenient, but I'd like to know if I can actually *rely* on that >>> behavior, or if I have to make arrangements to provide the ordering in a >>> separate parameter. >> >> You can rely on this if you are using Tomcat. I don't see the underlying >> design changing anytime soon. For other containers, YMMV. >> >>> I'd like to know which specs mention these things if they are indeed >>> specified in any of them. >> >> The only thing I am aware of is the query string before request body >> ordering in section 3.1. of the Servlet spec. > > Thanks for all that. Experiments with Tomcat showed that the parameter > order was what I was expecting. I was wondering if that was simply an > implementation detail or if it was spec-mandated. It seems it's an > implementation detail, though it may be a popular one. > > I wonder how difficult it would be to lobby the Servlet EG to codify > that behavior in the specification. I'm sure it would be advantageous to > all application developers if they could predict the order of > parameter-processing on the server side given the structure of their > URLs and HTTP POST form data. > > My past attempts to get Servlet EG to do anything have been fruitless, > even for simple things[1]. Any idea if this kind of request would ever > actually be considered?
I don't see why not. Open an issue and we'll see. > -chris > > [1] https://github.com/eclipse-ee4j/servlet-api/issues/130 Things should start improving now we have reached the point in Jakarta EE where we can evolve the specs and add new functionality. I hopeful for a LOT of additional clarity and a fair number of small new features in servlet.next. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
