Hi Another thing: Currently ParameterSupport is an internal part of the Sling Engine.
How about we move the ParameterSupport into a separate bundle and expose the ParameterSupport class as a utility class. This can then be leveraged by the Sling Engine itself but also by other pieces not running inside the Sling Engine. WDYT ? Regards Felix Am 13.01.2014 um 22:17 schrieb Felix Meschberger <[email protected]>: > Hi > > Well, all is not lost since, event if the AuthenticationHandler is reading > the parameters the Sling Engine's ParameterSupport actually kicks in ! (We do > this to support mutipart/form-data submission of login forms). > > Yet, I am a bit reluctant to replicate servlet container work here. > > Yet, on the other hand, we could maybe solve another problem more elegantly: > the problem of parameter encoding, where we currently employ a "reencoding" > technique which might be simplified if we do it ourselves. > > Yet, I still suggest you use multipart/form-data for any HTML form > submission. The other forms have serious drawbacks, particularly the > querystring method. > > Having said this, I could imagine taking a hybrid approach: > > (1) For url-encoded POST request, check whether InputStream is available > (1a) if available: > - decode query string > - decode input stream > (1b) if not available > - take all parameters from servlet container > (2) For form-data POST request > - decode query string > - decode POST input (as done today) > > WDYT ? > > Regards > Felix > > Am 13.01.2014 um 21:26 schrieb Alexander Klimetschek <[email protected]>: > >> Hi, >> >> Sling currently does not allow to read request parameters in their original >> order. I need this for a migrated servlet code that used to run on other >> servlet containers and was able to preserve the order (see below), thus has >> URL schemes where paramter order is crucial. >> >> Actually it is the java servlet spec that messed up things here: the HTML >> forms definition [1] clearly says that the order in the form encoding should >> be preserved (both for GET and POST), but the servlet API uses the "Map" >> interface and doesn't specify that this has to be an ordered map. Hence >> most/all the servlet containers implement this using a HashMap (Jetty [2], >> Adobe's CQSE; only Tomcat seems to be an exception [3]), and you can't rely >> on it. >> >> Note that while Sling does try to _ensure_ the order of parameters as noted >> on [4], this only means it keeps the container order, and only for the >> special case of "multipart/form-data" POSTs, where Sling actually does the >> decoding itself and does not use the servlet containers implicit decoding. >> However, the majority of POSTs and the ones I care about are not in >> multipart. >> >> Now, there can be a workaround: simply parse it yourself: >> - GET: use request.getQueryString() >> - POST: use request.getReader() >> >> This is what the servlet code base I mention is doing. >> >> However, the POST case relies on the fact that getReader() hasn't been >> called yet. But this is easily the case with form POSTs, since the first >> request.getParameter() will trigger decoding of the request body. And in >> Sling there will usually be at least one authentication handler that needs >> to do a request.getParameter(), and authentication handlers come before any >> servlet filter, so no luck to work around that. >> >> The proper way IMO would be to have sling take care of the >> correctly-ordered-re-decoding. This would need to be a change mostly in >> ParameterSupport [5] of the sling engine. It should probably be disabled by >> default (otherwise all parameters would always get decoded twice, once in >> the container and once in Sling) and could be opt-in on a per servlet basis >> - via means of some "sling.servlet.orderedparameters" option. Since the >> servlet is not resolved at the time of the auth handlers, this might in fact >> be tricky to do. >> >> WDYT? >> >> [1] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 >> [2] >> http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/util/MultiMap.html#33 >> [3] >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java?revision=1525696&view=markup >> [4] >> http://sling.apache.org/documentation/the-sling-engine/request-parameters.html >> [5] >> http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupport.java?view=markup >> >> Cheers, >> Alex >
