I've got a REST WebService and a PLSQL Package, from which i want to call the WebService.
The parameters for the call are located within the URI of the WebService.
htttp://myservice:8080/some/path/action?value1=123456&value2=some chars&value3=aGermanSonderzeichenCalledÄ
As you can see, there are 2 problems with the URI. First the whitespace for value2 and second the special character for value3.
That said, it is clear to me that the URI has to be encoded to a more friendly format.
The WebService desires UTF-8, so the URI is encoded with:
UTL_URL.ESCAPE(url,false,'UTF-8').
This results in the following URI:
htttp://myservice:8080/some/path/action?value1=123456&value2=some%20chars&value3=aGermanSonderzeichenCalled%C3%84
So far, so good. This encoded URI is passed to UTL_HTTP.BEGIN_REQUEST(url,'GET').
When I execute this request, and intercept it with Wireshark, i can see that the actual URI that got called is:
htttp://myservice:8080/some/path/action?value1=123456&value2=some%2520chars&value3=aGermanSonderzeichenCalled%25C3%2584
What we can see is, that UTL_HTTP escapes the reserved character '%' to %25.
So in my case the whitespace first got converted to %20 and after that to %2520.
What I'm looking for is a way to stop UTL_HTTP from escaping the reserved characters.
As an alternative, a way in which UTL_HTTP deals with the whitespace and special character, without me calling UTL_URL, would also work for me.
Related
Due to some odd circumstances I have the necessity to use uriQuery() in a Power Automate flow in order to extract the query string from an url.
This works as expected in most circumstances, except when the url contains special characters like accented letters, for example
http://www.example.com/peppers/Jalapeño/recipe #1.docx
In such cases the call triggers an error and the exception message shows a (partially) encoded version of my url (why?).
The template language function 'uriQuery' expects its parameter to be a well-formed absolute URI. The provided value was '......'
Obviously the url was indeed a well-formed, absolute URI.
Since the error only triggers when the url contains special characters I assumed that I had to encode the value before calling uriQuery(), yet nothing I tried seems to work (for example encodeUriComponent() ). And as expected nothing I could find on the web mentioned a similar issue.
As a last attempt I am asking here - does uriQuery() support this use-case? And if it does... how?
I am making GET Api request with space separated query param string, but Jmeter encoded that string before hit.
tried with HTTP Request Defaults but no use.
tried with url decode api but no use.
query param string =sourceId eq "fake_source_id_1"
import org.apache.jmeter.config.Argument;
URL url = ctx.getCurrentSampler().getUrl();
String decoded = URLDecoder.decode(url.toString(), "UTF-8");
As per HTML URL Encoding Reference
URLs cannot contain spaces. URL encoding normally replaces a space with a plus (+) sign or with %20.
If you need more "formal" source of information check out "Characters" chapter of the RFC 3986
A URI is composed from a limited set of characters consisting of
digits, letters, and a few graphic symbols. A reserved subset of
those characters may be used to delimit syntax components within a
URI while the remaining characters, including both the unreserved set
and those reserved characters not acting as delimiters, define each
component's identifying data.
Therefore you cannot send whitespace "as is" as a part of a HTTP Request URL, you need to either tick the relevant "URL Encode?" box for the required parameter in the HTTP Request sampler
Or use JMeter's __urlencode() function if you cannot use the above approach:
Check out Apache JMeter Functions - An Introduction article to get familiarized with JMeter Functions concept.
I am sending tokens via a POST request, but when I see them on the server it doesn't match up with what was sent.
"U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\nNT+g\n" <-- Original
"U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\\nNT+g\\n" <-- Result
Notice that the \n has been replaced with \\n. When I do the token lookup verification, of course, no result is found because the string I'm looking for is not the proper string anymore!
I'm not sure why this string is being auto changed like this or quite how to correct it. I'm just accessing this through the standard params like so.
token.verify(params["token"])
EDIT for further clarity
I'm viewing this from the terminal using the debugger gem. I have autoeval enabled and display with params["token"] without p or puts. I am not trying to create newline characters with \n. The literal \n is an actual part of the string that is received in the post. I randomly generate a token using a hashing and encryption library and the strings sometimes end up with these characters in them. If I run token.verify(params["token"]) from the debugger terminal I get nil back from the database as there is no match due to the extra backslash characters being added into the string.
If I directly run token.verify("U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\nNT+g\n") from the debugger terminal I get the correct record back from the database. This leaves me thinking that either Rack or Sinatra is auto escaping the "special" characters in the string before I get a chance to even touch it.
This has something to with the way Ruby is handling special characters. From irb you can see this with a quick check like this.
"\\n" == '\n'
Unexpectedly; at least to me, this returns true as they are treated the same. Rather than trying to deal with special characters coming across the wire I ended up just base 64 encoding everything.
I newly started using jmeter.
my application returns an url with encryption value as response which has to be passed as request to get the next page. The encryption value always ends with "=" ex. "http://mycompany.com/enc=EncRypTedValue=". while passing the value as request, the "=" is replaced with some other character like '%3d' ex "http://mycompany.com/enc=EncRypTedValue%3d" . Since the token has been changed my application is not serving the request.
It took me a while to understand this, unlike other languages and environments in network standards URIs (URLs) do not use quotes or some escape characters to hide special characters.
Instead, a URL needs to be properly encoded by encoding each individual parameter separately in order to build the complete URL. In JavaScript encoding/decoding of the parameters is done with encodeURIComponent() and decodeURIComponent() respectively.
For example, the following:
http://example.com/?p1=hello=hi&p2=three=3
should be encoded using encodeURIComponent() on each parameters to build the following:
http://example.com/?p1=hello%3Dhi&p2=three%3D3
Note that the equal sign used for parameters p1= ... p2= remain as is.
Do not try encode/decode the whole URL, it won't work. :)
Do not be fooled by what is displayed on a browser address bar/field, that is only the human friendly string, the moment you copy it to the clipboard the browser will encoded it.
Hope this helps someone.
Your application has a problem then, because that's the way it should be sent. Url parameters should be encoded as specified in rfc3986. Browsers can do it automatically even, so that's something that should be fixed on your web app, if it is not working.
If data for a URI component would conflict with a reserved character's
purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "#"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
What you are experiencing is URL Encoding - = is a reserved character in URLs and you cannot just append it to your URL unencoded. It needs to be encoded. This obviously already happened in your case. On the server side the url parameters need to be decoded again. This is the job of the container normally, though.
Basing on your use case you may with to consider one of the following approaches:
You can use Regular Expression Extractor Post Processor to capture you response and store it to JMeter variable. As variables as Java Unicode Strings you shouldn't experience any problem with extra encoding of your "=" symbol.
JMeter provides __urldecode function which you can utilize to decode your request.
You can pre-process the request with kind of __Beanshell function or BeanShell preprocessor to decode the whole URL with something like:
URLDecoder.decode(vars.get("your_URL_to be decoded"),"encoding");
If your are adding encryption values in the subsequent request as request parameter then make sure 'Encoding?' is unchecked
Use quotes for your values. E.g. -Jkey="val=ue"
I would like to receive a long string the contains spaces to my method in my web api
To my understanding i can't send a parameter with white spaces, does it have to be encoded in some way?
EDIT:
My content type is:
Content-Type: application/x-www-form-urlencoded
I've changed it to several other types but none of them allows me to receive a parameter with + instead of spaces
my post method signature is
public HttpResponseMessage EditCommentForExtension(string did, string extention, string comment)
Usually, parameters to an HTTP GET request are URL encoded. This means (among other) that spaces are replaced by "+".
Using + to mean "space" in a URL is an internal convention used by some web sites, but it's not part of the URL encoding standard. If you want to use + to means spaces, you are going to have to convert them yourself.
As you discovered, spaces (like everything else that needs encoding) should be encoded with %XX where X standards for a hex digit.
http://www.w3.org/Addressing/rfc1738.txt
The only thing that work for me is to add %20 instead of the spaces