URL encoding Ampersand via the REST Interface

Hello All,

I am pulling part images from ImageSvc over the REST API from a custom Javascript page I made. This has worked well but today I noticed that images with the ampersand (&) character in the name do not load. Investigating via the Swagger tools shows that I am getting this error:

A potentially dangerous Request.Path value was detected from the client (&)

I believe I am following correct percent encoding such that image name “ABC&XYZ” looks like “ABC%26XYZ” and the whole url looks like:

https://XXXXXXXX/api/v2/odata/{Company}/Erp.BO.ImageSvc/Images('{Company}','ABC%XYZ')

Luckily, the ampersand only occurs in a small subset of images, so as last resort, it might be possible to change their names…

Thoughts?

Try editing your post by placing a single tick before and after the URL you posted

https://xxxxxxxx/api/v2/odata/{Company}/Erp.BO.ImageSvc/Images('{Company}','ABC%25XYZ')

else what you typed (or pasted) gets convert for display on this board. Then we can see the actual contents of what you’re string is.

Also … You have Compnay as the second “Company”

And my thought would be to have the parameter un-escaped.

https://xxx/api/v2/odata/MC/Erp.BO.ImageSvc/Images('MC','ABC%XYZ')

vs

https://xxx/api/v2/odata/MC/Erp.BO.ImageSvc/Images('MC','ABC%25XYZ')

it is part of URL path, encoding will not help, you have to change web.config

https://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

Thanks All,

@Olga , I believe your comment put me on the right track. It seems to work when I change my URL to the following:

https://XXXXXXX/api/v2/odata/{Company}/Erp.BO.ImageSvc/Images?$select=ImageContent&$filter=ImageID%20eq%20'ABC%26XYZ'

I believe this moves the ampersand from the request path to the query string where its subject to different validation. Oddly, this seems the opposite of what is suggested in the article you linked? Edit: I misinterpreted the article

This this should satisfy my requirements! Thanks again!

1 Like

you did it right:

it’s worth mentioning that simply keeping the values as a part of the Query String (remember WAY back at the beginning of this post?) is easier, cleaner, more flexible, and more secure.

Got it. I must’ve misread.