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=18359>. 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=18359 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-06 21:24 ------- Tracing through the jmeter code, we have determined what is happening. JMeter is always URL decoding all form parameters during capture. What this causes is the BASE64 encoded form value on the page to be URL decoded and corrupted. This corrupted value is then either stored in the test sample or if you are using a URL Re-writing Modifier, stored internally corrupted. During the test this corrupted value is now URL encoded, and passed to the form which on the backend is URL decoded back into the corrupted value, causing the failure. In URLRewritingModifier.modify(HTTPSamplerBase, String) [line: 121] sampler.getArguments().removeArgument(getArgumentName()); [line: 129] sampler.getArguments().addArgument(new HTTPArgument(getArgumentName(), value, true)); [line: 130] True is passed in explicitly to the constructor of the HTTPArgument indicating that the value is URL encoded. HTTPArgument then runs the value through the decoder before storing it. Running a BASE64 encoded string through the URL decoder corrupts the string. The URL Re-Writing Modifier (and any other element that parses/stores form values) should allow an option to indicate whether or not the value is url encoded. -- 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]
