Welcome Guest! Log in
×

Notice

The forum is in read only mode.
Stambia versions 2.x, 3.x, S17, S18, S19 and S20 are reaching End of Support January, 15th, 2024. Please consider upgrading to the supported Semarchy xDI versions. See Global Policy Support and the Semarchy Documentation.

The Stambia User Community is moving to Semarchy! All the applicable resources have already been moved or are currently being moved to their new location. Read more…

Topic-icon Question HTTP REST Web Service with URL replacement - Prevent automatic URL encoding

More
05 Apr 2018 07:57 #1 by craigacgomez
Hi,

I want to use Stambia S19.0.7 to make a REST web service call where I have a HTTP URL replacement parameter which is an email address. I have configured the WSDL metadata and set a "Input Part" which uses the "http:urlReplacement" binding type and my URL has the input part name patter in {}.

<url>/json/{email}

I mapped my database table to the input part, and the output JSON response to a target table. (Oracle 12c database).

But what I did notice was that the "Call Webservice" is encoding my HTTP URL Replacement. Essentially, it is replacing the "@" symbol in my mapped input part with the HTML encoded equivalent "%40". And this causes my web service to fail because it can no longer parse the URL part.

The database table has This email address is being protected from spambots. You need JavaScript enabled to view it.
This is mapped to the Input Part "email" which uses the "http:urlReplacement" binding type and "string" data type
What I expect =
<url>/json/user@email.com
What the Stambia web service invokes =
<url>/json/user%40email.com

Is there any way to prevent this automatic URL encoding?
More
05 Apr 2018 10:00 #2 by Thomas BLETON
Hi,

As far as I know there is no way to disable this encoding.
It is quite common (and safe - and respectful of the http standards) to encode special chars in URL query strings.
Is there a way for your webservice to correctly decode the Query String? Which technology does this server use?
More
05 Apr 2018 16:19 #3 by craigacgomez
Hi Thomas,

Thank you for your quick response. I understand the use case for standard URL encoding and actually would normally always use that.

But the service I am trying to use is an email verification service. It's written in Go and is an open source project which I can modify and self host, but I wanted to avoid self hosting. The service is call Trumail

trumail.io

And it does not currently seem to accept encoded email addresses.

Cheers,
Craig