| Author |
Message
|
| MatthewDCampbell |
 Posted: Wed Sep 30, 2020 8:01 am Post subject: ascii encode URL |
 |
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
Using Toolkit 9.0.0.1 and making an outbound HTTP request using the HTTP Request Node where the URL is set before entering the node:
| Code: |
| SET OutputRoot.HTTPRequestHeader."X-Original-HTTP-URL" = ... |
Need to ascii encode the url. Can this be done with CAST? For example, if an url had a space then the ascii equivalent is %20. |
|
| Back to top |
|
 |
| mgk |
| Posted: Wed Sep 30, 2020 8:47 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
So normally it's parts of the query string that require URL Encoding. If this is indeed your case you can look up the 'QueryString' LocalEnvrionment override for the HTTPRequest Node here: https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac04595_.htm
An example would be:
| Code: |
| SET OutputLocalEnvironment.Destination.HTTP.QueryString.param1 = 'my"Value"1'; |
where the quotes ("") in the value of Param1 (and any other parameters) would be url encoded for you.
FYI, the more common override for the Request URL would be the 'RequestURL' field rather than 'X-Original-HTTP-URL' as in:
| Code: |
| SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://ibm.com/abc/'; |
I hope that helps.
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| MatthewDCampbell |
| Posted: Wed Sep 30, 2020 10:17 am Post subject: |
|
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
@mgk Appreciate the tip on overriding the url. Regarding ascii encoding the example given is with query string but I assume the same applies to the URL (which is where I need ascii encoding):
| Code: |
| SET OutputLocalEnvironment.Destination.HTTP.RequestURL = '"' | someString | '"' |
where someString is a variable that might contain spaces, swedish characters etc. |
|
| Back to top |
|
|
| MatthewDCampbell |
| Posted: Wed Sep 30, 2020 10:15 pm Post subject: |
|
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
Wrapping a string in double quotes with both OutputLocalEnvironment.Destination.HTTP.RequestURL and OutputRoot.HTTPRequestHeader."X-Original-HTTP-URL" does not ascii encode the URL. A series of REPLACE works:
| Code: |
CREATE FUNCTION AsciiEncode(IN valueString CHARACTER) RETURNS CHARACTER
BEGIN
DECLARE washedString CHARACTER;
-- Default
SET washedString = REPLACE(valueString, ' ', '%20');
-- Swedish characters
SET washedString = REPLACE(washedString, 'ö', '%C3%B6');
...
RETURN washedString;
END; |
|
|
| Back to top |
|
|
| abhi_thri |
| Posted: Wed Sep 30, 2020 11:30 pm Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...not directly related to the issue you are dealing but noticed that you are using a very early version of iib9.
You may be aware but please note that IIB v9 is already out of support (extended support may still be available), so it may be worth looking to migrate to v10 or v11. Even if you are continuing on v9 it may be worth upgrading to the latest fixpack as otherwise you will stumble upon the numerous issues which are fixed only in the latest fixpacks.
https://www.ibm.com/support/pages/fix-list-ibm-integration-bus-version-90 |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Oct 01, 2020 6:00 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi, so firstly, you should not wrap the string in double quotes - just provide a string variable like my example above. However, that will probably not fix the URL encoding problem.
As has already been mentioned v9 is very old and its always best to move to a newer version if you can - certainly for new development. That said you do have a couple of options if you have to stay with v9. Firstly, if you know that there will only ever be a few chars that need encoding, then your replace scheme will be simplest. If it can be any char, then you could actually look at creating a simple Java method (or .NET method depending on your platform) and call that from ESQL to pass in the string and pass back the encoded version.
If you can move to v10 or above then I have a better solution - the ESQL language has added two new functions:
and
which you could use. The snag is that they are currently missing from the docs in the knowledge centre and may also be missing from the toolkit. There is an internal defect raised to document and expose them but for now if the the toolkit rejects the syntax for the function when using the v10 or 11 toolkit then you can use an "Executable Comment" to force the toolkit to deploy the syntax to the runtime which will then accept it - or you can raise a PMR and ask IBM to provide a patch for you to use it.
The executable comment syntax to test this out would look like this:
| Code: |
DECLARE washedString CHARACTER;
/*!{ SET washedString = URLENCODE(valueString); }!*/ |
I hope that helps.
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Last edited by mgk on Thu Oct 01, 2020 11:58 am; edited 1 time in total |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Oct 01, 2020 11:54 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
OK, so I have another update here. A colleague of mine has just run a test on the latest v10 code for this and I believe the code would do what you want "out of the box" but that would require that you move to the latest v10 fixpac...
The quick test was to use this URL:
| Code: |
| SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://localhost:11007/somevalue with Swedish ö'; |
And this is the HTTP Request Line constructed and sent by the request node
| Code: |
| POST /somevalue%20with%20Swedish%20%C3%B6 HTTP/1.1 |
This works with any url encoding needed in the path and if you have query strings then you can use the method I initially posted. So it looks like if you can move to v10 or above it should work without needing fixes or executable comments!
I hope that helps.
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| MatthewDCampbell |
| Posted: Thu Oct 01, 2020 9:47 pm Post subject: |
|
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
@abhi_thri version 9 is used with legacy code where there is no plan for upgrading so stuck with 9.
@mgk Cool that ascii encoding is automatically handled in 10. Appreciate you'll confirming with a test. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 02, 2020 4:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MatthewDCampbell wrote: |
| @abhi_thri version 9 is used with legacy code where there is no plan for upgrading so stuck with 9. |
Pedantically, it's not legacy code if you're changing it.
The product is also backwards compatible so you can deploy v9 objects to v10.
Make sure whoever's made that decision has accepted the risks in writing. This forum is littered with posts from people who's WMB/IIB code has started showing problems when the underlying OS has been patched/updated, the database has been patched/updated, a new network device has been introduced, etc., etc. and it's always seen as an WMB/IIB problem. So make sure your get out of jail free card is safe.
Freezing legacy code only works if you freeze the entire technology stack it's running on.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
