are WCF service arguments automatically URI decoded or do I manually do it?
EDITED TO ADD:
When I originally put forward this answer I seem to remember having verified it in a test. Upon #JohnSaunders comment below I revisited with a new project. And found that a console app submitting the string above returned the string exactly as it had been submitted, without having URI encoded it. It may be that I did something unexpected previously. Anyway, #JohnSaunders is correct.
Original Incorrect Answer:
No, they are not, and yes you have to URI encode them if you're expecting special characters.
If you were to submit this to a WCF service in the stream of data passed to it:
"http://localhost/users/email/bill#microsoft.com"
It would show up on the server like this:
"bill"
The "#microsoft" gets removed
The passed data must be URI encoded to get it all to pass through.
Related
Using C#, I've been trying to receive XML as a string, from the client, in a SOAP WCF service (not my choice, it's the way the client is choosing to send it) and I couldn't get it to work correctly in the WCF Test Client. I thought that I had found the problem. I assumed that the backslashes in the closing XML Tags would cause WCF Test Client to parse incorrectly and send a null value to my service without throwing any exceptions or anything in the WCF Test Client. See the link below.
http://programmersranch.blogspot.com/2014/08/c-wcf-backslash-limitation-in-wcf-test.html
However, that does not seem to be the issue, as the slashes in XML are / slashes and the slashes that cause problems are \ slashes. Any suggestions? Here is the string I am copy + pasting into the string parameter for one of my service methods in WCF Test Client. I have escaped the quotation marks and so on to avoid issues with the string parsing, but it doesn't work even after escaping them.
<?xml version=\"1.0\"?><QBXML><QBXMLMsgsRs><ItemNonInventoryQueryRs requestID=\"SXRlbVF1ZXJ5fDEyMA==\" statusCode=\"500\" statusSeverity=\"Warn\" statusMessage=\"The query request has not been fully completed. There was a required element 'your item name' that could not be found in QuickBooks.\"/></QBXMLMsgsRs></QBXML>
Also, I want to point out that if I enter a string like "BOB" or "sally2135" or something that's not XML at all, it receives the string just fine. It just doesn't like the XML string.
Thanks!
As it turns out, the solution is embarrassingly simple. Just minutes after asking a question I've been working on for a few hours now, I found the answer. Upon removing the \ before all of the quotation marks in the string, I received the XML string without a problem.
I'm attempting to make a web request through a WebClient in a Windows Phone 8.1 Application. The web request contains a set of search terms, which whilst building the request signature are percent encoded as such: OAuthTools.UrlEncodeStrict(searchTerms), this is done because the search terms likely contain spaces. I then add all other parameters, and generate a signature. The request URL will then look something like this:
http://platform.fatsecret.com/rest/server.api?format=json&max_results=10&method=recipes.search&oauth_consumer_key=******&oauth_nonce=ksoordxpd5oahp9e&oauth_signature=Uxq3pmkTkRrASO%2Bmoiujs24BtT4%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1420634671&oauth_version=1.0&page_number=0&search_expression=pumpkin%20pie
As you can see, the final parameter, search_expression=pumpkin%20pie is encoded correctly. However, when putting this URL into a URI object (as the WebClient.DownloadStringAsync method requires), the URL is decoded to:
http://platform.fatsecret.com/rest/server.api?format=json&max_results=10&method=recipes.search&oauth_consumer_key=******&oauth_nonce=ksoordxpd5oahp9e&oauth_signature=Uxq3pmkTkRrASO%2Bmoiujs24BtT4%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1420634671&oauth_version=1.0&page_number=0&search_expression=pumpkin pie
Removing the escaped spacing for the search_expression parameter. This results, in this case, in an invalid OAuth signature (as the parameters change), but using an unescaped search_expression with spaces also results in an invalid OAuth signature (I assume because REST parameters should not contain spaces). Is there a way to ensure that the URI class does not decode my URL string? I have found this answer explaining that a workaround is to include:
<uri>
<schemeSettings>
<add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes" />
</schemeSettings>
</uri>
Inside of the Web.config or App.config file. However, there appears to be no suitable config file to place this in inside a Windows Phone 8.1 development environment (I have tried adding it to packages.config and the app manifest, neither of which had any effect). Is there another way around this issue? Or alternatively, is there another way I can send a web request using a raw string, as opposed to through a URI object?
I have been trying to debug an issue communicating with a web service, and it led me to a question. I was wondering what the difference between WebClient.UploadValues and WebClient.UploadData was in C#. I found the answer to that here .NET WebClient.UploadValues vs WebClient.UploadData
The answer as essentially that UploadData submits content in the body of the request, where as UploadValues acts like submitting values from a form. I would have thought they were the same thing. When you submit content in the body of a post, it usually looks something like "key=value&key2=value2...". (when the content type is application/x-www-form-urlencoded)
I thought they were the same thing until I noticed something. Using UploadValues gives me a totally different result than UploadData. In the case of the service I am communicating with, using UploadValues succeeds and UploadData returns the error "Request format is invalid".
So what exactly is the difference between a form post data and the content in the body of a request? Are they actually different things? Does an http request contain a querystring, body, AND form data?
Thanks!
UPDATE Okay, so I know what my problem was and I think I know the answer to most of my question.
Upload Values submits the body with content type application/x-www-form-urlencoded. I am not entirely sure what content-type is used for UploadData by default, but you can set the header explicitly so it will take whatever you give it.
My original confusion arose when I was trying to do this by composing an HttpWebRequest and writing the content to the RequestStream. I was setting the Content Type too late. I guess it needs to be specified BEFORE writing to the Stream.
Form data is sent in the body of the request.
Okay, so I know what my problem was and I think I know the answer to most of my question.
Upload Values submits the body with content type application/x-www-form-urlencoded. I am not entirely sure what content-type is used for UploadData by default, but you can set the header explicitly so it will take whatever you give it.
My original confusion arose when I was trying to do this by composing an HttpWebRequest and writing the content to the RequestStream. I was setting the Content Type too late. I guess it needs to be specified BEFORE writing to the Stream.
Form data is sent in the body of the request.
I am stuck at an unexpected issue in my project. The issue is that there is a URL produced on the fly in my code that I have to submit it to a RESTful web service via a GET request. For e.g. the URL to submit looks like this: http://mysampleserver.com:8080/calc/8999/bpaX
The RESTful server accepts URL as its last parameter in the format below:
http://myRestfulAPI.domainname.com/capture/bbbb/http://mysampleserver.com:8080/calc/8999/bpaX
I also used System.Net.HttpUtility.UrlEncode(....) to encode the "URL to submit" first to incorporate it in the RESTful service call.
That resulted in getting the error below:
System.Web.HttpException: A potentially dangerous Request.Path value was detected from the client (:)
To try to resolve it, I followed the steps described per this web page but no luck.
I am using MVC 4 to implement the RESTful API in C#.
Any clue or idea how to get around this showstopper issue?
There are at least two solutions I can think of.
Change your RESTFul service to use post, because you send information to your server, and potentially it will change your resource status, based on HTTP protocol , you should use POST anyway.
You can also encode your url with Base64
The steps that you've tried are the correct steps. See also this question potentially dangerous... which is the same issue.
There are a number of characters that .NET doesn't allow in in a URL by default, and the : is one of them (as a query string, at least). They are 'potentially dangerous'. Making this change to the configuration file allows these characters to be passed through to your application.
You need to Url.Encode the url in the query string (mvc parameters) otherwise it is interpreted as more URL encoding for MVC to decode as parameters. Try something like #Url.Encode(yourStringObject) and pass it as the last value or as a query (i.e. &q=url)
I've got an app in the Windows 8 store that uses a WCF service hosted on Azure. When I use my proxy program, UltraSurf, the app fails to connect to the service with this error:
The content type text/html of the response message does not match the
content type of the binding (text/xml; charset=utf-8). If using a
custom encoder, be sure that the IsContentTypeSupported method is
implemented properly. The first 472 bytes of the response were:
'
The requested URL could not be retrieved
'.
The URL mentioned in the quote is the default 'can't find the page Url' that UltraSurf produces and so the error message is probably of no use. The question is, why/how does Ultrasurf block/get in the way of my connection?
Can anybody shed some light on what's going on and why it fails connect please?
Thanks!
Working without much information here, but I'd suspect that the problem is that the proxy is just being a little picky.
I believe that your error message basically says, "I'm expecting to get back 'text/xml' data, but what I see is 'text/html' data". That's probably not because it can actually see 'text/html' data coming back, but rather, because it's not seeing the content type header from the response telling it that it is xml data.
I don't know exactly how you implemented your WCF service, or what type of data it's set up to return, but you might want to ensure that you explicitly set the content type somewhere in your code before the return and see what happens. Something like:
Response.ContentType = "text/xml";
The only other thing that springs to mind is that your application might be picky about the content type for XML in general. There's a bit of, um... subtle difference... around whether the appropriate content type for XML is 'application/xml' or 'text/xml'. It's possible that your service is presenting the one that your proxy doesn't like?