[
https://issues.apache.org/jira/browse/SLING-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776384#action_12776384
]
Tobias Bocanegra commented on SLING-1178:
-----------------------------------------
ok. i agree that the servlet spec does not define the order of the request
parameters.
however, multipart/form-data does:
http://www.w3.org/TR/html401/interact/forms.html, 17.13.4 Form content types
...
A "multipart/form-data" message contains a series of parts, each representing a
successful control. The parts are sent to the processing agent in the same
order the corresponding controls appear in the document stream. Part boundaries
should not occur in any of the data; how this is done lies outside the scope of
this specification.
...
and since a multipart-post is also exposed via the request parameter map, i
have no possibility to decompose the multipart post myself if i want to
preserve the order of the parameters (parts).
> Preserve request parameter order throughout the entire request stack
> --------------------------------------------------------------------
>
> Key: SLING-1178
> URL: https://issues.apache.org/jira/browse/SLING-1178
> Project: Sling
> Issue Type: Improvement
> Components: Engine, Servlets
> Affects Versions: Servlets Post 2.0.4, Engine 2.0.6
> Reporter: Tobias Bocanegra
> Priority: Minor
> Attachments: ordered_params-r834673.patch
>
>
> When posting a form to the sling post servlet i encountered that the order of
> the request parameters is not preserved,
> even the browser sends the params according to the submitted form.
> for example the following form:
> <form name="input" action="/content/testform" method="POST">
> <input type="hidden" name="./sen...@delete"/><br/>
> Address 0: <input type="text" name="./sendTo/0/address" /><br/>
> Text 0: <input type="text" name="./sendTo/0/text" /><br/>
> Address 1: <input type="text" name="./sendTo/1/address" /><br/>
> Text 1: <input type="text" name="./sendTo/1/text" /><br/>
> Address 2: <input type="text" name="./sendTo/2/address" /><br/>
> Text 2: <input type="text" name="./sendTo/2/text" /><br/>
> <input type="submit" value="Submit" />
> </form>
> results in:
> deleted("/content/testform/sendTo");
> created("/content/testform/sendTo");
> created("/content/testform/sendTo/2");
> modified("/content/testform/sendTo/2/address");
> modified("/content/testform/sendTo/2/text");
> created("/content/testform/sendTo/1");
> modified("/content/testform/sendTo/1/text");
> created("/content/testform/sendTo/0");
> modified("/content/testform/sendTo/0/text");
> modified("/content/testform/sendTo/0/address");
> modified("/content/testform/sendTo/1/address");
> i first thought it's just the ModifyOperation which uses a HashMap instead of
> a LinkedHashMap:
> Map<String, RequestProperty> reqProperties = new HashMap<String,
> RequestProperty>();
> but the params arrive out of order already from the request.getParameterMap().
> i guess the "ParameterMap" needs to extend from LinkedHashMap, too:
> class ParameterMap extends LinkedHashMap<String, RequestParameter[]> ...
> after fixing those 2 classes, the order is correct:
> deleted("/content/testform/sendTo");
> created("/content/testform/sendTo");
> created("/content/testform/sendTo/0");
> modified("/content/testform/sendTo/0/address");
> modified("/content/testform/sendTo/0/text");
> created("/content/testform/sendTo/1");
> modified("/content/testform/sendTo/1/address");
> modified("/content/testform/sendTo/1/text");
> created("/content/testform/sendTo/2");
> modified("/content/testform/sendTo/2/address");
> modified("/content/testform/sendTo/2/text");
> i'll attach the patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
