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]
