DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41837>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41837 ------- Additional Comments From [EMAIL PROTECTED] 2007-03-20 11:38 ------- Thanks for your info, I think we have solved this problem now. Analysis : Your jsp pages was helpful in analyzing this. I've added a bit of functionality to the results.jps page. I've added use of the commons-io.jar and commons-fileupload.ja, so that I can see what is posted when doing a "multipart/from-data" post. I'll attach the updated war file. First of all, if you are testing pages which are using multipart/form-data, then you should turn of the "Capture HTTP Headers" setting in the Proxy Server. See bug 27780. Bug 27780 also explains that when running the test plan after you have captured it, jmeter will issue a "application/x-www-form-urlencoded" request even though the proxy server received a multipart/form-data. But if you are a bit lucky, that should does not cause problems for you. I think the bug is in the MultipartUrlConfig class, which is handling the parsing of a multipart/form-data post request for the proxy server. If you are in a multipart/form-data post request, then the parameter values which are part of the multipart is not encoded by the browser. But the MultipartUrlConfig does the following : " } else if (parts[i].indexOf("name=") > -1) { int index = parts[i].indexOf("name=\"") + 6; String name = parts[i].substring(index, parts[i].indexOf("\"", index)); index = parts[i].indexOf("\n", index) + 2; String value = parts[i].substring(index).trim(); this.addEncodedArgument(name, value); } " So the MultipartUrlConfig assumes that parameter values which are part of a multipart/form-data has been URL encoded. I think that is the wrong assumption. I think it should do a "this.addArgument(name, value);", to add a parameter value which has not been URL encoded by the browser. I'll attach a patch to fix this. Read more on http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4 And perhaps read section 6 og http://www.ietf.org/rfc/rfc2045.txt So the multipart/form-data can be encoded by specifying the "Content-Transfer-Encoding" in the multipart. But let us say that for now, the Proxy does not support that. It has been useful to do this investigation. I was already planning to fix bugs 27780, 33435, 41518 (which I think is the same as 27780), and 19128. I hope to have 27780 fixed within a couple of weeks. However, what I plan to do first, is to reorganize the "HTTP Request" GUI slightly, because I need to add an "HTTP POST" parameters section, so that the user can choose if he wants to do a "x-www-form-urlencoded" or a "multipart" post if only parameters are present. There also needs to be room in the GUI to add more files. I'm thinking about using tabs in the lower part of the GUI, one tab names "Options", one tab named "Parameters", one tab named "File uploads". That was all for now. It would be good if you could test the patch I'll add shortly, and see if things works then. And I guess Sebb will also look at the patch, and apply it if he agrees. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
