Why I do something like a POST to a restler method, the output seems to always start with a newline character. How do I prevent that newline character from being put into the output?
I've never noticed that behaviour. Could it be some of your files having a bare new line outside of the PHP tags?
Sample API request I've just made in a test project of mine:
Related
I developed one application in Mulesoft for calling a SOAP webservice. While making GET call to a SOAP web service from Postman, query parameter value starting with # is not getting considered by my Mulesoft mapping.
e.g: http://localhost:8080/appName?queryParam1=#abc
In my mule application, the value for queryParam1 is coming as empty value. Could some one explain the technical reason for this. Is # is considered as escape character from Postman or Mulesoft Transform Message activity? Thanks in advance
I also faced the same issue in my API, in URI anywhere in between comes the '#' character the rest of your URI will go blank and the 404 HTTP error will occur.
I suggest you to get the value in query parameter without # character and later in the API code or flow prefix it. This will work.
Hope this will resolve your problem.
You will have to encode characters such as #. Refer this link for complete list of such characters. In your example:
Change: http://localhost:8080/appName?queryParam1=#abc
To: http://localhost:8080/appName?queryParam1=%23abc
I'm new to React native and Expo, but started to write my own app on it, with the same backend i used with my Cordova app.
Unfortunately i hit a roadblock trying to recreate the btoa() function from browsers, that i use to authenticate users with Basic authorization.
No matter what i try, i can't seem to get the same result as i did with btoa. I tried researching the subject, but i can't find a solid answer what's the difference between Base64.encode() and btoa().
I know i'm doing something wrong. When i try out the post request with Postman, i get the correct Basic auth token with it. But when i do it in code with base64 encoding(tried multiple libraries), the result differs.
Example:
test#test.com:asdasd
in postman: "dGVzdEB0ZXN0LmNvbTphc2Rhc2Rhc2Q="
in app(to utf8, then base64): "W29iamVjdCBBcnJheUJ1ZmZlcl0="
Relevant part of my code:
const utf8_enc = utf8.encode(email+':'+password);
const b64_enc = base64.encode(utf8_enc);
console.log(b64_enc);
Used libraries:
Base64- https://www.npmjs.com/package/base-64
UTF8 - https://github.com/mathiasbynens/utf8.js
Please tell me why are the two different, and how can i recreate the Postman version.
Thank you!
Ok, I see what's happening now. If you follow the docs for that utf8 package, it won't import correctly in React Native. You can see that it's not imported correctly by trying to access decode() or version as both will give you undefined. I think the reason is because they don't support es2015 modules (see this rejected PR). This package will however work fine in Node.js or in the browser.
Oddly enough, you do have access to encode() when you import. It just doesn't do what you think it does. When you attempt to use encode(), all it actually returns is the string: [object ArrayBuffer]. In fact, no matter what string you pass to it, it'll always return the same result. Now if you use btoa() on this string (with or without UTF-8 conversion since there's no difference in this case), you will see that you get that same output in the browser: W29iamVjdCBBcnJheUJ1ZmZlcl0=
So, how to get around this?
If all you expect are extended ASCII strings, then you don't need to encode it in UTF-8 as they will all be within the valid character set. So you can just do:
base64.encode(email+':'+password);
However, if you anticipate supporting all Unicode characters, then you have a few options to convert that string:
Fork the utf8 package to have it support modules/exporting.
Copy paste the entirety of the utf8 source and put it in your own local library and export the functions.
Write your own UTF-8 encoder/decoder using the method suggested here which itself is from the MDN Documentation.
So there's a reference to a solution, here is the relevant encode part of the code from the MDN documentation turned into a function:
function utf8encode(str) {
return encodeURIComponent(str).replace(/%([0-9A-F]{2})/g, function(
match,
p1
) {
return String.fromCharCode(parseInt(p1, 16));
});
}
I don't know that I have the terminology completely correct, but it seems that there are some default behaviors for script resolution in Sling (which I'm using as part of Day CQ). For example, .infinity.json returns a representation of the node and its children. Also, if I have a piece of content that I normally would access with a .html extension, I've been able to use a .xml or .json extension to get a representation of that data. However, if I use a .txt extension, I get nothing back, even though as far as I can tell, I do have scripts that should match the request (eg GET.jsp). Are these behaviors documented somewhere?
GET.jsp will match a request ending with .html, as Sling considers html as the default representation. To activate a JSP script for the .txt rendering, you need to name it txt.jsp
See http://sling.apache.org/site/servlets.html for details.
I have a really weird WCF problem here...
We're connecting to a crappy third-party web service; it was a nightmare to even get it going, we had to create a custom WCF binding since those guys decided to use "ISO-8859-1" as their text encoding (instead of UTF-8 like everyone else on the web), and the other settings were messy, too - and not documented anywhere, of course...
It's been working ok for a while now, but suddenly, some of our data coming back in mangled up. We expect to get back names of places, and being in Switzerland, some of those have German umlauts in them. But for the past two or three months, we suddenly get back
Hünibach
instead of the proper
Hünibach
So the ü (u umlaut) is mangled.
No problem, I figured they finally switched to UTF-8, and I changed my custom binding to use UTF-8 as its text encoder instead of ISO-8859-1 - but no luck - no I'm getting:
EXCEPTION: System.ServiceModel.Security.MessageSecurityException
The HTTP request was forbidden with client authentication scheme 'Basic'.
What the f????? The service is protected by a username/password which we pass in using the ClientCredentials of WCF. Seems that changing the text encoding somehow messes up the credentials !?!?! Weird.....
OK - back to ISO-8859-1, and I just tried to interpret the response payload as UTF-8 - again no luck :-( Tried with UTF-16, UTF-32, UTF-7 even, Unicode, BigEndianUnicode - all to no avail.
So how on earth do I get back my proper umlauts, and still be able to call that bloody service... works just fine in SoapUI, btw.....
Any ideas?? I'm desperately grasping at any straws you might throw me!!
Try inspecting the data you are getting back and see what numeric codes they are using to represent it. Umlaut is one of those characters in 8859-1 that shares code with other characters.
See second para in - http://en.wikipedia.org/wiki/%C3%9C#Typography
Actually, I finally figured out what the trouble was.
For some reason, changing the sample CustomTextEncoder (provided by Microsoft in the WCF & WF samples) to use UTF-8 instead of ISO-8859-1 doesn't work.
On the other hand, ripping out the custom text encoder from my custom binding and just using the standard TextMessageEncoder that WCF provides from the get go (which uses UTF-8 by default) did work.
Don't ask me why.... that's just the facts I found.....
My Web host has refused to help me with this, so I'm coming to the wise folks here for some help "black-box debugging". Here's an edited version of what I sent to them:
I have two (among other) domains at dreamhost:
1) thefigtrees.net
2) shouldivoteformccain.com
I noticed today that when I host a CGI script on #1, that by the time the
CGI script runs, the HTTP GET query string passed to it as the QUERY_STRING
environment variable has already been URL decoded. This is a problem because
it then means that a standard CGI library (such as perl's CGI.pm) will try to
split on ampersands and then decode the string itself. There are two
potential problems with this:
1) the string is doubly-decoded, so if a value is submitted to the script
such as "%2525", it will end up being treated as just "%" (decoded twice)
rather than "%25" (decoded once)
2) (more common) if there is an ampersand in a value submitted, then it
will get (properly) submitted as %26, but the QUERY_STRING env. variable will
have it already decoded into an "&" and then the CGI library will improperly
split the query string at that ampersand. This is a big problem!
The script at http://thefigtrees.net/test.cgi demonstrates this. It echoes back the
environment variables it is called with. Navigating in a browser to:
http://thefigtrees.net/lee/test.cgi?x=y%26z
You can see that REQUEST_URI properly contains x=y%26z (unencoded) but that
QUERY_STRING already has it decoded to x=y&z.
If I repeat the test at domain #2 (
http://www.shouldivoteformccain.com/test.cgi?x=y%26z ) I see that the
QUERY_STRING remains undecoded, so that CGI.pm then splits and decodes
correctly.
I tried disabling my .htaccess files on both to make sure that was not the
problem, and saw no difference.
Could anyone speculate on potential causes of this, since my Web host seems unwilling to help me?
thanks,
Lee
I have the same behavior in Apache.
I believe mod_rewrite will automatically decode the URL if it is installed, however, I have seen the auto-decode behavior even without it. I haven't tracked down the other culprit.
A common workaround is to double encode the input parameter (taking advantage of URL decoding being safe when called on an unencoded URL).
Curious. Nothing I can see from here would give us a clue why this would happen... I can only confirm that it is an environment bug and suspect maybe configuration differences like maybe rewrite rules.
Per CGI 1.1, this decoding should only happen to SCRIPT-NAME and PATH-INFO, not QUERY-STRING. It's pointless and annoying that it happens at all, but that's the spec. Using REQUEST-URI instead of those variables where available (ie. Apache) is a common workaround for places where you want to put out-of-bounds and Unicode characters in path parts, so it might be reasonable to do the same for query strings until some sort of resolution is available from the host.
VPSs are cheap these days...