On 10 November 2010 16:55, Frank Bezema <[email protected]> wrote: > Yes, tried body unescaped, same result, > rgds > Frank
It cannot be exactly the same, unless the unescaping is not working. What is the value of the variable created by the Regex Extractor, and what is the raw HTML it is derived from? Use the Debug Sampler to show the value of the variable. > > Op 10 nov 2010 om 16:52 heeft sebb <[email protected]> het volgende > geschreven:\ > >> On 10 November 2010 15:45, Frank Bezema | Everett >> <[email protected]> wrote: >>> >>> Hi, >>> >>> So, if unescaped is not possible with Regular_Expression_Extractor, then >>> what? >> >> Have you tried using Body unescaped? >> >>> How to do this? How is for example the first response available in a >>> beanshell postprocessor? Any examples? >>> >>> Rgds, >>> >>> Frank. >>> >>> ----- Original Message ----- >>> From: "sebb" <[email protected]> >>> To: "JMeter Users List" <[email protected]> >>> Sent: Wednesday, November 10, 2010 1:01:22 PM >>> Subject: Re: prevent POST encode in jmeter >>> >>> On 10 November 2010 10:18, Frank Bezema | Everett >>> <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> The "later" response returns encoded. >>>> >>>> So, a value from URL1 response is regex extracted in a variable >>>> $SAMLresponse. >>>> >>>> Then later, in another HttpClient sampler, this SAMLresponse is posted >>>> to URL2 (in the request). >>>> In the posted HTML, the value of $SAMLresponse is URLencoded, which is >>>> not correct. This URLencoded value is received by the server at URL2. (the >>>> value is urlencoded, htmlencoded and base64encoded. That's one urlencoding >>>> too much.) >>>> >>>> When manually, outside jmeter, urldecoding the value copied from the >>>> posted HTML, and sending it to URL2, it works. >>>> >>>> So, it seems that jmeter urlencodes the value of $SAMLresponse. >>>> Any way to prevent this? >>> >>> >>> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Regular_Expression_Extractor >>> >>> "Body (unescaped) - the body of the response, with all Html escape >>> codes replaced. Note that Html escapes are processed without regard to >>> context, so some incorrect substitutions may be made. " >>>> >>>> rgds, >>>> >>>> Frank. >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Adrian Speteanu" <[email protected]> >>>> To: "JMeter Users List" <[email protected]> >>>> Sent: Monday, November 8, 2010 2:02:19 PM >>>> Subject: Re: prevent POST encode in jmeter >>>> >>>> hello, >>>> >>>> is jmeter POST request being encoded (in request tab of view results >>>> tree)? >>>> it's not very clear from your mail, my understanding is that the "later" >>>> response returns encoded. >>>> if jmeter sends the request as you have pasted it bellow, when you POST >>>> the >>>> data initially, then it means that the application must do some >>>> character >>>> escaping and that depends on the application alone. if so, when jmeter >>>> receives the page that contains what you post-ed, it might be shown >>>> escaped >>>> as you have seen bellow. >>>> >>>> otherwise, I can't reproduce the situation where jmeter sends that text >>>> encoded without the encode checkbox being used. >>>> >>>> any other thoughts? I can't think of any reasons for the behaviour >>>> described. >>>> >>>> --Adrian S >>>> >>>> On Fri, Nov 5, 2010 at 6:26 PM, Frank Bezema >>>> <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> Jmeter seems to encode a variable in POST: >>>>> >>>>> original value regex extracted from earlier response data, HTTP request >>>>> (shown in view results table): >>>>> >>>>> ...LjA6
cHJvdG... >>>>> >>>>> in a later request, the view results table shows the (HTTP request >>>>> HTTPClient) request POST gets encoded to : >>>>> ...LjA6%26%23xa%3BcHJvdG... >>>>> >>>>> My service seems to choke on this. >>>>> >>>>> The "encode?" checkbox is clear/off for the request parameter. >>>>> >>>>> Any idea how to prevent jmeter to behave like this? >>>>> >>>>> (jmeter 2.4, java version "1.6.0_22") >>>>> >>>>> rgds & tia, >>>>> >>>>> Frank. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
