Hello,
I was wondering if anyone run into issue with API that returns 500 because of the “/”?
The part is in the database but it seems the API is not liking it. Any suggestion?
Have you tried URL encoding it?
It looks like it did encode it for him:
should the values entered in the form be enclosed in single quotes?
@snguyen - do you only see this on PartNum’s with a /
in them?
Hi Calvin,
Yes, this issue only happens with partnumbers with “/” others partnumber without “/” are returning fine with 200 status
What does the app server event log report. Should have something in there for 500’s
there are number of characters that cannot be part of URL, see, for example
https://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx
It’s odd that the tool only escapes the /
character. Normally most URL encoding would escape the .
too.
What happen’s if you escape it in the Partnum field, like: 'EC-PC-FK6-.5\/18.25'
??
(Just taking wild guesses here)
Thanks Olga for the information
Hey all, I was able to get the PartNum with different OData methods and use the $filter . Thanks for all the input
I find it odd that this other OData method encoded everything after ../PriceLstPart
While the first one only encoded the /
Also, it’s not just the encoding…
The first one seems to have parameters in the middle of the URL
and calls two functions
PriceLsts
PriceLstParts
Did you ever try the first one with just the PartNum and UOMCode (neither enclosed in single quotes)?
Hi Calvin,
I have tried them in neither enclosed single quotes and still doesn’t work. Also, those parameters for the methods are required. It won’t let me “try it out” if those are not filled out.
I didn’t mean just those two fields. I meant just their values (without the quotes).
But this is just me being overly curious… Don’t spend anymore time if you’ve got a solution.