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
Related
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.
Given this piece of code:
<%
Response.Write Server.URLEncode("a doc file.asp")
%>
It output this for a while (like Javascript call encodeURI):
a%20doc%20file.asp
Now, for unknow reason, I get:
a+doc+file%2Easp
I'm not sure of what I touched to make this happen (maybe the file content encoding ANSI/UTF-8). Why did this happen and how can I get the first behavior of Server.URLEncode, ie using a percent encoding?
Classic ASP hasn't been updated in nearly 20 years, so Server.URLEncode still uses the RFC-1866 standard, which specifies spaces be encoded as + symbols (which is a hangover from an old application/x-www-form-urlencoded media type), you must be mistaken in thinking it was encoding spaces as %20 at some point, not unless there's an IIS setting you can change that I'm unaware of.
More modern languages use the RFC-3986 standard for encoding URLs, which is why Javascript's encodeURI function returns spaces encoded as %20.
Both + and %20 should be treated exactly the same when decoded by any browser thanks to RFC backwards compatibility, but it's generally considered best to use %20 when encoding spaces in a URL as it's the more modern standard now, and some decoding functions (such as Javascript's decodeURIComponent) won't recognise + symbols as spaces and will fail to properly decode URLs that use them over %20.
You can always use a custom function to encode spaces as %20:
function URL_encode(ByVal url)
url = Server.URLEncode(url)
url = replace(url,"+","%20")
URL_encode = url
end function
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.
Is there a way to say (programmatically, I mean their API) the Google URL shortener not to produce short URL with characters like:
0 O
1 l
Because people often make mistake when reading those characters from displays and typing them elsewhere.
You cannot request the API to use a custom charset, so no.
Not a proper solution, but you could check the url for unwanted characters and request another short URL for the same long URL until you get one you like. Google URL shortner issues a unique short URL for an already shortned URL if you provide an OAuth token with the request. However I am not sure if a user is limited to one unique short URL per a specific long URL in which case this won't work either.
Since you're doing it programmatically, you could swap out those chars for their ascii value, '%6F' for the letter o, for instance. In this case, just warn the users that in doubt, it's a numeral.
Alternatively, use a font that distinguishes ambiguous chars, or better yet, color-code them (or underline numerals, or whatever visual mark)
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"