CLONE -MultiPartFilter ignores the query string parameters

This bug seems not to be fixes in a satisfactory way — or I did not understand what it is about. If I have this kind of form:

<form action='http://localhost:8080/dump/info?x=1&y=2' method='post'
enctype='multipart/form-data'>
<p><input type='text' size='80' name='y' value='22' /></p>
<p><input type='text' size='80' name='z' value='33' /></p>
<p><input type='submit' name='send' value='send' /></p>
</form>

and test this with jetty-6.1.21, i.e. I simply enter the jetty directory and start jetty with" java -jar start.jar" then the dump info page shows me:

Request Parameters:
z: 33
send: send
y: null
y[0]: null
y[1]: 22
x: 1

So the query parameters are somehow copies over, as you see x and two y (one from the query string, the other from the form input field). Yet the ones copied over from the query string have value null.

The problem is either in the way the arguments are copied over or the way getParameter(s) handle them. Not knowing the intent of the MultiPartFilter author it's not easy for me to decide.

What happens is, that when the parameters from the query string are copied over in the line:

MultiMap params = new MultiMap(request.getParameterMap());

then the MultiMapFilter.map will contain entries with a string as key and a string array as a value. E.g. the entry for x will have a String as key with value x and its value will be String[]

. After adding the form parameters to it the map will have

x String array with one element with value "1".
y Array with two entries:
[0] ist another String array with one element with value "2".
[1] is a byte array with value [0x50,0x50] (the parameter value "22").
z is a byte array with value [0x51,0x51] (the parameter value"33").

The MultiPart.Wrapper getParameter method fails in this way:

when it aks for the value for y it gets the array of array which it cannot handle, a it expects either single byte[] or String or an array of Strings.

It handles correctly the case of x=1 though.

The MultiPart.Wrapper getParameterValues method fails in this way:

When it asks for the value of x it gets an ArrayList containing the String-array. It iterates over the array list expecting only byte-arrays and strings in it and fails.

When it asks for the value of y it gets an ArrayList containing the String-array anf the byte-array. It iterates over the array list expecting only byte-arrays and strings in it and fails.

So the Wrapper get methods do not handle the map as it was constructed. There is either an error in the get methods or in the way the map is built in the first place.

Investigating further I see that MultiMap uses LazyList.add to add itself several values to one parameter relying on its behavior to go from 0 elements to a single element to a list of elements. But LazyList add assumes, that what was there before is either a single Object or a ArrayList. A String-array is not a ArrayList and thus considered as a single element.

Thus I'd say the error is either in MultiMap.putAll, or in the way MultiMap.putAll is used by MultiPartFilter. Thus one of those two solution need to be implemented.

Solution 1:

MultiMap.putAll looks at the values of the passed maps, and if it is a String-array then it converts that array to a LazyList containing the arrays value. I.e. replace the line

put(entry.getKey(),entry.getValue());

by

Object k=entry.getKey();
Object v=entry.getValue();
if (v instanceof String[])

else

Solution 2:

In MultiMapFilter the line

MultiMap params = new MultiMap(request.getParameterMap());

is replaced by a loop which iterates of the original map and adds each item individually using putValues where necessary.

MultiMap params = new MultiMap();
for (Map.Entry entry:request.getParameterMap()) {
Object k=entry.getKey();
Object v=entry.getValue();
if (v instanceof String[])

else

}

Above code is untested. Not knowing the intent of the writer of above mentioned classes I don't know which of the two solution is the "proper" one.

The fix in jetty 6 an 7.
I iterate over entries to build the MultiMap
and then I fixed the bug in the getParameter(String) method on the request wrapper.