I'm using Node.js and I found out that when I send GET call to a server with C++ then in SQL binding I get C(blank space)(bankspace) (checked with console.log(req.query.keywords) so essentialy the same length of the string, but no chars there.
When I use SELECT * FROM jobs WHERE keywords LIKE' %c++%'; it works normally and gives me results. Is there something I don't know about Node - like it's dropping signs like +?
I think the issue you're having is the same one outlined here: URLs and plus signs
The issue is that a GET is going to use the query string in the URL and plus signs need to be formatted (or encoded) similar to how a space is formatted as %20 in URLs. You could probably use or create a UrlEncoding method in your application.
In Node, I believe you can use something like: encodeURIComponent('C++')
The URL encoding for + is %2B
Related
We are running into an issue with Zapier where it's URL encoding our query parameter names which then doesn't get parsed correctly on API side.
Our parameters might look like this:
Where.Name[eq]=john
however the parameter after it's being used in Zapier ends up looking like this:
Where.Name%5Beq%5D=john
Is there any way how to tell Zapier to not URL encode the query parameter name part?
Try using skipEncodingChars field in z.request (from version 11.3.2+)
https://github.com/zapier/zapier-platform/blob/a3bf8eefa6d0dc41c4001bd74f48873eb85ad1d9/packages/schema/docs/build/schema.md#:~:text=to%20false.-,skipEncodingChars,-no
skipEncodingChars | no | string | Contains the characters that you want left unencoded in the query params (req.params). If unspecified, z.request() will percent-encode non-ascii characters and these reserved characters: :$/?#[]#$&+,;=^#`\.
I've noticed that when i send a url like this:
http://localhost:3000/register/register_user/?sig=zaQ/876CwJMEEmrJqAOYHyEKBXy2s03NDmk+3FsXPr4=
what comes through when I use it to compare to the expected result using params[:sig] in the controller is this:
zaQ/876CwJMEEmrJqAOYHyEKBXy2s03NDmk 3FsXPr4=
For some reason the '+' sign that was in the url at the 9th character from the end of the string has been converted to a space.
Not sure why that happens, whether it only happens with + signs or what.
The result returned by Digest::SHA256.base64digest(data) has this plus sign so my validation of the signature is failing.
What's the best way to fix this? Will it suffice in the general case just to convert '+' signs into spaces before the comparison or is the re some less ugly way to address?
You'll need to url encode it. Either do a search and replace for + with %2B or force the encoding using open-uri.
require 'cgi'
sig = "zaQ/876CwJMEEmrJqAOYHyEKBXy2s03NDmk+3FsXPr4="
puts CGI.escape(sig)
Tested it this time.
irb(main):008:0> require 'cgi'
=> true
irb(main):009:0> CGI.escape('zaQ/876CwJMEEmrJqAOYHyEKBXy2s03NDmk+3FsXPr4=')
=> "zaQ%2F876CwJMEEmrJqAOYHyEKBXy2s03NDmk%2B3FsXPr4%3D"
irb(main):010:0>
I am using ORACLE APEX 5.0.1
I am passing an url string to an APEX application where I have encoded all special caracters, if there is one or more %3A (colon) in the url APEX seemes to truncate the value I am passing.
This affects only the last variable I am passing and only the remaining part after the last %3A, but if I place a %3A at the very end of the url it works in APEX.
I have asked about this in other forums and it seems to be a relative unknown issue in APEX, haven't got any relevant answer that explains the issue.
This example pass values to tre fields
"...../apex/f?p=118:32:::::P32_XX,P32_YY,P32_ZZ,:100030,486,VMKF%3AU%202012%3A50"
P32_XX, and P32_YY get the value ok
P32_ZZ only get the value "VMKF:U 2012"
but if I put a %3A at the end of the url like this
"...../apex/f?p=118:32:::::P32_XX,P32_YY,P32_ZZ,:100030,486,VMKF%3AU%202012%3A50%3A"
it works ok and P32_ZZ gets the value "VMKF:U 2012:50".
I have tested this in Windows Explorer 11, Google Crom and Mozilla Firefox (latest version) with the same behavior.
And I have the same behaviour if I use a literal colon (:)
Appreciate the help
The issue is that the colon is a separator for the different parts of the APEX URL. I am surprised that using %3F doesn't fix it, but the solution is to surround the whole value by \...\ like this:
...../apex/f?p=118:32:::::P32_XX,P32_YY,P32_ZZ,:100030,486,\VMKF%3AU%202012%3A50\
Note that you don't even need to escape the colons now:
...../apex/f?p=118:32:::::P32_XX,P32_YY,P32_ZZ,:100030,486,\VMKF:U%202012:50\
I am testing the photos.batchGet endpoint.
Per the API docs, it takes two URL parameters "view" and "photoIds". When I try the photoIds parameter, the request only works with one photoId. Using multiple photoIds fails.
I tried using a delimeter between the photoIds in the string (by using a comma, pipe, and space). I also tried not using a delimeter at all. Not using a delimeter returns a response for the last photoId in the string, but not for any of the other photoIds. In short, none of my requests appear to be working. Am I doing something wrong?
Also, depending on server configuration, I think it's recommended for the URL length to be under 2,000 characters. Anything above 30 photoIds would create URLs longer than this.
That being said, maybe it would be better to make this a POST request that accepts a JSON request body? Just a thought, but think this would be better suited. A lot of our tours are above 30 scenes, and we even had a tour with 700 scenes!
The description of the batchGet function was updated. Per the documentation you should pass photoIds as a string and the URL query parameter should be photoIds=<id1>&photoIds=<id2>.
I am wondering if it is possible to prevent YQL from URL encoding a key for a datatable?
Example:
The current guardian API works with IDs like this:
item_id = "environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy"
The problem with these IDs is that they contain slashes (/) and these characters should not be URL encoded in the API call but instead stay as they are.
So If I now have this query
SELECT * FROM guardian.content.item WHERE item_id='environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy'
while using the following url defintion in my datatable
<url>http://content.guardianapis.com/{item_id}</url>
then this results in this API call
http://content.guardianapis.com/environment%2F2010%2Foct%2F29%2Fbiodiversity-talks-ministers-nagoya-strategy?format=xml&order-by=newest&show-fields=all
Instead the guardian API expects the call to look like this:
http://content.guardianapis.com/environment/2010/oct/29/biodiversity-talks-ministers-nagoya-strategy?format=xml&order-by=newest&show-fields=all
So the problem is really just that the / characters gets encoded as %2F which I don't want to happen in this case.
Any ideas on how this can be achieved?
You can also check the full datatable I am using:
http://github.com/spier/yql-tables/blob/master/guardian/guardian.content.item.xml
The URI-template expansions in YQL (e.g. {item_id}) only follow the version 3 spec. With version 4 it would be possible to simply (only slightly) change the expansion to do what you want, but alas not currently with YQL.
So, a solution. You could bring a very, very basic <execute> block into play: one which adds the item_id value to the path as needed.
<execute><![CDATA[
response.object = request.path(item_id).get().response;
]]></execute>
Finally, see the diff against your table (with a few other, minor tweaks to allow the above to work).