I’m invoking a REST web service that performs a GET to obtain some attachment data. The parameters it takes are SRNumber, External_Id, attachmentId, and attachmentName. There are certain invoke URLs that work in the browser, but don’t work when I invoke the service through code. One in particular I’m testing has the following parameters:
- SRNumber = 1000
- ExternalId = USERID7/27/2012 10:43:00 AM
- attachmentId = 1-2H1USPQ
- attachmentName = File name goes here
Here’s the URL formatted with URL-encoded parameters:
When I attempt to do a GET through code, though, I am receiving an error. It appears that the web service is reading the URL-encoded ‘/’ character as if it’s a delimiter in the URL (I stepped through the code to verify that when the string was built, the ‘/’ in the External_Id was URL-encoded.)
Here’s the code I’m using the build the URL String:
requestURL = ConfigurationManager.AppSettings["Server"] +
ConfigurationManager.AppSettings["Service"] +
"Service_Record_Attachment_Query/SRNumber/" +
System.Uri.EscapeDataString(SRNumber) + "/External_Id/" +
(ExternalID.Equals(null) ? "" : System.Uri.EscapeDataString(ExternalID)) +
"/attachmentId/" + System.Uri.EscapeDataString(AttachmentID) +
"/attachmentName/" + System.Uri.EscapeDataString(AttachmentName) + "/";
After building the request String, I use that to create an HTTPWebRequest:
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(requestURL);
Then I get an error back saying the attachment does not exist since it’s only searching for “USERID7” and excluding the rest of the attachment name.
Am I doing something wrong in my code that could be causing the ‘/’ character to be interpreted as a delimiter? I don’t understand why it returns a successful response when I put the invoke URL in the browser, but the same invoke URL through code returns an error.
Use a tool like Fiddler to look at what is actually passing across the network wire in the browser and code cases. The browser may be double-escaping the ‘/’ chars in the URL, or your code may not be escaping it the way you think it is. Looking at the HTTP request on the wire should tell you a lot.