I am creating a WCF Service with a method
[OperationContract]
[WebGet(UriTemplate = "acl/f={fullFileName}")]
string GetACL(string fullFileName);
fullFileName is a full path to a network file, or a file on the host.
The host is a Windows Service with webHttpBinding and behavior configuration.
I want to call this from a browser using something like
http://localhost/webservice/acl/f=[my network path here]
I have tried .../acl/f=file://\server\share\file.ext
.../acl/f=file://c:\file.ext
In the browser I receive "Endpoint not found".
I know this works because I can call .../acl/f=file.txt and I get back the proper response from my service indicating that the file was not found. So the method is getting called correctly when I don't use slashes of anysort in the URI.
Any thoughts on this will be greatly appreciated.
Thanks,
beezlerco at hotmail...
You need to encode the slashes, colons, and technically the periods as well.
\ should be %5C
/ should be %2F
. should be %2E
: should be %3A
for most other special characters see http://www.asciitable.com/ and use '%' plus the hex column on that table.
I believe HttpUtility.UrlEncode is what you are looking for.
(For a detailed description, see Using HttpUtility.UrlEncode to Encode your QueryStrings)
Related
i have a problem with using character when i want to get user information by using email
the problem is special character in the email
because the api link not supports character for example
this is the Route im using in the api
[Route("api/v1/Users/{Email}")]
and this is the link
api/v1/Users/majed email.com
any special character let the GET not even see the request link
how can i solve this problem ?!
In most scenarios it has been found that a 404 is returned if an email address is sent. The issue is usually caused by the "." in the email address.
If you add a trailing slash it should resolve your issue.
api/v1/Users/majed#email.com/
You could use URL encoded format of the string.
The string majed#email.com would encoded be majed%40email.com.
You can read more at W3 Shools URL Encoding Reference.
I'm currently working with an email confirmation after registration using ASP.NET Identity.
This library provides a token generation which is needed to complete the registration. This token is used in our application in the following path:
https://localhost/#/account/{token}/setup
And the token is generated by invoking:
var emailToken = _userManager.GenerateEmailConfirmationToken(newUser.Id);
Once I have my token generated, I add it in the path by doing a string.Format this way:
string.Format("https://localhost/#/account/{0}/setup", HttpUtility.UrlEncode(emailToken));
The result looks like this:
https://localhost/#/account/AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQhGTTMUWVHDgOwC9T9AAAAAACAAAAAAAQZgAAAAEAACAAAAAqo%2fiAv8iIn7Zox9pS3MOUMVNisAo7Bnada6%2f9wKEe6wAAAAAOgAAAAAIAACAAAABUu7WkD9vHvN2EDz2%2bqGwvJ4j6gj%2f4PaBTbI861jfEcWAAAADJV74LZjKAXv5v1FqYVuWLyTpPBCnLfopSi3rsEEwMHFKwltHL3moL2h%2fvYVs%2fu3LB%2br5Qytuu%2fZYOUWQTY5KzBqHeZoi7RJ02emDI0NTRhIKxfSGGIdbYxuAjsW14G0BAAAAACsC8L%2bdUDzFMgKUOkxWhKofAz8L0mH5VFEt8Oq%2fKYsxIiu4fiA2sGlPfDhhKQnV2lg%2ba8qHydUjqmyfxNex0Pg%3d%3d/setup
but when I open this url in the browser I get:
...and so on!
What I see is that the url is encoded correctly in the body of the email, but is decoded when I open it in the browser by replacing the encoded "%2f" to "/". This leads to an invalid route in my application being that I expect the "/" to be a separator between different resources.
Any thoughts of this behaviour?
References:
Another guy with my problem too
It's probably decoding it because it considers it part of the path.
I would suggest you explicitly treat it as a parameter. That will tell the browser not to decode it. For instance, instead of having this path:
https://localhost/#/account/AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQh..........
Use this path:
https://localhost/#/account/?t=AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQh......
Notice the addition of ?t= after the end of the account path.
Then consume the t parameter in your application. That will tell the browser that the value at the end is not to be decoded as part of the path but rather preserved in encoded form because it's a parameter.
This would obviously change the path you have (because of the setup part) so adjust accordingly.
In the middle of developing a Web Api 2 REST service, we have discovered a routing problem. The endpoint is as follows:
.../{email}/...
The problem is that the email could contain special characters such as '+', which results in a 404 resource not found.
We would really like for the user of the service, to be able to specify the email in the URL. But since the email also legally can contain an '&', this can't just be moved to an URL parameter. How would we go about solving this?
Regards
Frederik
UrlEncodeUnicode and UrlDecode should be helpfull in your case.
No, encoding and deconding can only work if yyou're in control of the client and server operations. If otherwise, the best way is to call the endpoint as such
www.yourwebsite.com/api/account/create?email='{email with any characters}'
I am trying to send a request to an url like this "http://mysite.dk/tværs?test=æ" from an asp.net application, and I am having trouble getting the querystring to encode correctly. Or maybe the querystring is encoded correctly, the service I am connecting to just doesn't understand it correctly.
I have tried to send the request with different browsers and logging how they encode the request with Wireshark, and I get these results:
Firefox: http://mysite.dk/tv%C3%A6rs?test=%E6
Ie8: http://mysite.dk/tv%C3%A6rs?test=\xe6
Curl: http://mysite.dk/tv\xe6rs?test=\xe6
Both Firefox, IE and Curl receive the correct results from the service. Note that they encode the danish special character 'æ' differently in the querystring.
When I send the request from my asp.net application using HttpWebRequest, the URL gets encoded this way:
http://mysite.dk/tv%C3%A6rs?test=%C3%A6
It encodes the querystring the same way as the path part of the url. The remote service does not understand this encoding, so I don't get a correct answer.
For the record, 'æ' (U+00E6) is %E6 in ISO-LATIN-1, and %C3%A6 in UTF-8.
I could change the remote service to accept the UTF-8 encoded querystring, but then the service would stop working in browsers and I am not really interested in that. Is there a way to specify to .NET that it shouldn't encode querystrings with UTF-8?
I am creating the webrequest like this:
var req = WebRequest.Create("http://mysite.dk/tværs?test=æ") as HttpWebRequest;
But the problem seems to originate from System.Uri which is apparently used inside WebRequest.Create:
var uri = new Uri("http://mysite.dk/tværs?test=æ");
// now uri.AbsolutePath == "http://mysite.dk/tv%C3%A6rs?test=%C3%A6"
It looks like you're applying UrlEncode over the entire URL - this isn't correct, paths and query strings are encoded differently as you've seen. What is doing the encoding of the URI, WebRequest?
You could manually build the various parts using a UriBuilder, or manually encode using UrlPathEncode for the path and UrlEncode for the query string names and values.
Edit:
If the problem lies in the path, rather than the query string you could try turning on IRI support, via web.config
<configuration>
<uri>
<iriParsing enabled="true" />
</uri>
</configuration>
That should then leave international characters alone in the path.
Have you tried the UrlEncode?
http://msdn.microsoft.com/en-us/library/zttxte6w.aspx
I ended up changing my remote webservice to expect the querystring to be UTF-8 encoded. It solves my immediate problem, the webservice can not be correctly called by both PHP and the .NET framework.
However, the behavior is now strange in browsers. Copy pasting an url like "http://mysite.dk/tv%C3%A6rs?test=%C3%A6" into the browser and then pressing return works, it even corrects the encoded characters and displays the location as "http://mysite.dk/tværs?test=æ". If then reload the page (F5) it still works. But if I click on the location bar and press return again, the querystring will become encoded with latin-1 and fail.
For anyone interested here is an old Firefox bugreport about the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=284474 (thanks to #dtb)
So, it seems there is no good solution.
Thanks to everyone who helped though!
This worked fine in IIS 6. Now using IIS 7.5 and cannot figure the problem out. Trying to get a bespoke app working, it's a file manager. When attempting to access files with spaces in the files names IIS encodes the URL as files/This+is+a+filename.doc and throws a cannot find file. I need it to encode the URL as files/This%20is%20a%20filename.doc.
Been looking at URL rewrite but cannot get my head around it.
Any ideas?
You can change url encoding. No need for regular expressions.