Yes, tried body unescaped, same result,
rgds
Frank
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: jmeter-user-
[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]
