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-19 11:35 ------- I've looked into this now, but haven't gotten much further. If you can point us to a public web server where we can test, that would help a lot. Perhaps you know of some public sites which has demos of applications using JSF, where you and we could recreate the problem. If not, I suggest you try the following : Use the proxy to record the test plan. Then execute the test plan, and see which sample fails. Then I suggest you fix the value of that Request parameter by hand in the GUI, ie change the space to a +, and then re-execute the test to see if it works. That should work. If it still does not work, then I'm not sure if it is a Proxy decoding problem. Alternative, you could add a method in the org.apache.jmeter.protocol.http.util.TestHTTPArgument (the unit test for HTTPArgument), and write a unit test for the encoding and decoding of your problematic values, and supply that code, and we could have a look at it. Something like : public void testDecoding() throws Exception { // Test to try to recreate problem in bug 41837 // This is how the MultipartUrlConfig.addEncodedArgument method // creates and HTTPArgument for a parameter value that is // received as part of a POST request HTTPArgument arg = new HTTPArgument("test_for_bug_41837", "H4sIAAAAAAAAAO19CXgcxZV/ayRZh2UsyZLlS/YQ29gGPDrm0OGQIMuyLVY+sM3", true); if (arg.getName().equals(arg.getEncodedName()) && arg.getValue().equals(arg.getEncodedValue())) { arg.setAlwaysEncoded(false); } // The value must be encoded before it is sent to web server assertTrue(arg.isAlwaysEncoded()); } I've run that test code, and it seems to behave correct to me. Spaces as encoded as + in an URL, and then when the Proxy gets the value, it decodes the value, and put it into the HTTPSampler that is put into the test plan, because we prefer to show unencoded values in the GUI. What is the "Encode?" property value for the request parameter in the HTTP Request node that is put into the test plan ? If "Encode?" is true, then I don't think it is a problem that the "+" is shown as a " " in the GUI, because when the test is run again, it will be encoded into "+". Perhaps you could attach a test plan created by the proxy, which shows the problem ? Or you could attach a screengrab of the problematic HTTP Request in the test plan ? It would be good if you could run with the latest nightly build of jmeter. What is the "content-type" and "charset" for the web pages you are serving ? If you are using UTF-8, perhaps you could try to add "UTF-8" as the value of the "Content encoding" in the HTTP Request, you need the latest nightly build to have that field. I think you should try that first. That functionality was added as part of bug 41705. So if your application is expecting UTF8 data, but you have not set the "UTF-8" "Content encoding" on the HTTP Request, then you might get problems. I'll look more into this issue, if you can provide us with information so we get a few steps closer to solving this. -- 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]
