I have an REST API implementation in the Gateway, one of the endpoints is used to upload/download files. I have come across a scenario where using ‘%’ special character in the url is causing 500, 401 errors. Below are various responses of the requests to the endpoint. http://sampleApp/files/word.docx - this works. http://sampleApp/files/word%.docx - in postman this results in ‘Could not get response’ error. http://sampleApp/files/word%25.docx - in postman first requests throws ‘500 - Internal Server Error’, 2nd request throws ‘401[ISS.0084.9013] Invalid or expired session identifier error’, and this repeats.
Shouldn’t the encoding (‘%’ → ‘%25’) work? Is there other configuration to handle special characters?
[Update] Pre-formatted the hyperlinks to prevent html from skewing the query.
My url request is below, it is url-encoded, however as mentioned earlier this results in 500, 401 errors. Also, i don’t see any log entries for the URL requests having ‘%’ in Analytics pane of Admin portal, but for those URL’s without ‘%’ is logged…
http://sampleApp/files/word%25.docx
Note: Since you replied to my initial query i have applied formatting to the hyper-links to prevent html formatting where ‘%25’ was interpreted as ‘%’.
I double encoded the ‘%’ (i.e., ‘%2525’), this registers an entry in the API Gateway, however, with double encoding there seems to be error invoking downstream application, the error logged is below. I have ‘Straight Through Routing’ configured for the API’s, the downstream application call seems to be missing the encoding - the downstream application expects single encoding (i.e., ‘%25’).
Hi @Manjunath_SP ,
The reason why i asked to double encode the special character (%) is, when you encode it once then it reaches API Gateway as %, again when we try to invoke the Native service with % we will get this Malformed escape pair exception. But if we double encode this then it reaches API Gateway as %25 thereby it will reach the Native Service without any error. Even i had the same setup like you in my local and it worked with double encoding.
What is the status code and error message that you’re getting after this double encoded URL.
I carried out further tests and below are the results,
Without encoding (/files/word%.docx): API Gateway does not register the call.
With single encoding (/files/word%25.docx): API Gateway does not register the call.
With double encoding (/files/word%2525.docx): API Gateway registers the call, however it fails to call downstream API because the /files/word%2525.docx is translated to /files/word%.docx
With triple encoding (/files/word%252525.docx): API Gateway registers the call, and it successfully calls downstream API.
Note: Downstream API works with single encoding (i.e., %25).
Question: Why should there be triple encoding? I believe the API should work with single encoding, the API Gateway must decouple itself from the downstream API’s and it should handle encoding in a standard way (i.e., carrying the encoding presented to it to the downstream).