I am using this code to download file from server and parse data from JSON notation:
WebClient wcl = new WebClient();
Uri url = new Uri(tickurl);
string srlz = wcl.DownloadString(url);
var dict = (new JavaScriptSerializer()).Deserialize<Dictionary<string, dynamic>>(srlz);
When I use it with http://deepbit.net/api/ + my token (URI returns JSON data) it works well.
But with https://mtgox.com/code/data/ticker.php it stucks on 3rd line of the function(data downloading).
What am i doing wrong? Both URLs return same JSON formatted data.
[add] it's not issue with https, this code works well enough with other https services. i am wondering if this could be a problem with SSL cert.
SOLVED: turned off SSL certificate validation. thanks
I suspect it's failing due to a security problem. When I fetch with wget, I get:
ERROR: certificate common name www.mtgox.com' doesn't match requested host namemtgox.com'
It's fine when I fetch with wget using the --no-check-certificate flag.
I don't know whether you can persuade WebClient not to check certificates... but a better option would obviously be to get the certificate fixed.
Alternatively, try this URL instead: https://www.mtgox.com/code/data/ticker.php - note the www at the front. That fetches in wget without any issues.
The Url: https://mtgox.com/code/data/ticker.php doesn't even open up in browser. It starts downloading the 'ticker.php' file. Your server is misconfigured. The code is fine. Most probably the server is not properly configured to process .php files as scripts.
it is a certificate error like Jon Skeet said.
Have a look here to find a easy solution
WebClient + HTTPS Issues
you shouldn't use this for all request, only for debugging
Related
I am trying to get THIS example to work (.Net Client Libraries example) - however everything I have attempted results in an error:
Basic authentication requires a secure connection to the server.
There is another example using the REST Api at the top of the page I linked and this works perfectly fine. For some reason, I just cant get this working using the libraries!
My code looks like this:
Uri uri = new Uri("http://adtfs:8080/tfs/{MyCompany}");
string personalAccessToken = "MyPATString";
VssBasicCredential credentials = new VssBasicCredential("", personalAccessToken);
using (ProjectHttpClient projectHttpClient = new ProjectHttpClient(uri, credentials))
{
IEnumerable<TeamProjectReference> projects = projectHttpClient.GetProjects().Result;
}
As I mentioned, using the same URL and PAT in the REST API example works fine, but for the libraries, I just cant get beyond the error mentioned above.
Am I missing something or can anyone suggest anything else I could try please?
Change http=>https from http://adtfs:8080/tfs/{MyCompany} to https://adtfs:8080/tfs/{MyCompany} ... easiest answer there was I guess works glad it helped ... but just as precautionary tale, I'll add this for posterity, you should use https anyways if the server supports it (had an app that was working sometimes slow, sometimes fast and I couldn't figure out why until I saw this https://httpvshttps.com, turns out the https tunnel was always being recreated cause I put http instead of https and the server was set to always switch to https).
I am trying to call a Web API using HttpWebRequest(Console Application).
To upload the file, I am using the code snippet provided by #Cristian Romanescu ont this question Upload files with HTTPWebrequest (multipart/form-data)
If I set the req.ProtocolVersion as HttpVersion.Version10,I get Bad request when I try to do req.GetResponseStream().
If i set the req.ProtocolVersion as HttpVersion.Version11,I get Could not create SSL/TLS secure channel. when i try to do req.GetResponseStream().
If tried to post the data using POSTMAN, but even Postman says Could not get any response".
If I try to hit the URL using IE-11 I get HTTP 404.[I know i am not posting the actual file], but Chrome displays the custom/appropriate error message.
I tried the solutions already provided on stackoverflow, but unfortunately they do not solve my problem.
Thankyou.
Which solution you have tried? It's worth trying the following if you haven't already - write following before you actually invoke the service:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
Two things that I was doing wrong.
The Server wanted date in yyyy-MM-ddTHH:mm:ss, I was providing the date in yyyy-MM-ddTHH:mm:ss.ssss Format(DateTime.UtcNow.ToString("o")). This was the cause of Could not create SSL/TLS secure channel
The server wanted the parameters in request body as well. I had passed the parameters only as query string. This was the cause of HTTP 404
In the process, I had asked a guy outside my team to help. He had asked me to see if there were any SSL related errors. To do this he asked me to add
System.Net.ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(AcceptAllCertifications); and define AcceptAllCertifications, which was not the case. So to resolve the issue, I had to take care of the things mentioned above.
Try to create self signed certificate from your server and add it to your client machine.
Create self signed certificate (Server side)
Import self signed certificate (Client side)
We use Request.Url.GetLeftPart(UriPartial.Authority) to get the domain part of the site. This served our requirement on http.
We recently change site to https (about 3 days ago) but this still returns with http://..
Urls were all changed to https and show in browser address bar.
Any idea why this happens?
The following example works fine and returns a string with "https":
var uri = new Uri("https://www.google.com/?q=102njgn24gk24ng2k");
var authority = uri.GetLeftPart(UriPartial.Authority);
// authority => "https://www.google.com"
You either have an issue with the HttpContext class right here, or all your requests are still using http:
You can check the requests HttpContext.Current.Request.IsSecureConnection property. If it is true, and the GetLeftPart method still returns http for you, I think you won't get around a replacing here.
If all your requests are really coming with http, you might enforce a secure connection in IIS.
You should also inspect the incoming URL and log it somewhere for debugging purposes.
This can also happen when dealing with a load balancer. In one situation I worked on, any https requests were converted into http by the load balancer. It still says https in the browser address bar, but internally it's a http request, so the server-side call you are making to GetLeftPart() returns http.
If your request is coming from ARR with SSL Offloading,
Request.Url.GetLeftPart(UriPartial.Authority) just get http
I'm working on a web application that runs with ASP.Net 3.5
Somewhere in the application, I'm making calls to an external system. This call consists on downloading a string from a specific url :
string targetUrl = BuildMyUrl();
WebClient wc = new WebClient();
string data = wc.DownloadString(targetUrl);
This code works quite well with a acceptable response time (under 500ms).
However, in specific cases this response time is over 15 seconds. I can reproduce the behavior, and I can clearly see the long time is on the DownloadString call.
I don't understand why this occurs in my scenario.
You will say : "Hey, it's the target system that is slow". But I was not able able to reproduce the behavior outside my application (I've build a small console application that isolate the faulting code. Never get any issue).
I don't know where to look now to understand the issue. What can cause a simple download data to be be lengthy ?
FYI: the target system is an authentication service. The target url is of kind :
httpS://mysystem/validate?ticket=XXXYYY
Maybe the https protocol is the issue.
Does using WebClient class under IIS can alter the behavior of the WebClient ?
[Edit] I've tried :
To explicitly set the Proxy property of the WebClient object to null
I've replaced the DownloadData call by this code :
var req = (HttpWebRequest)WebRequest.CreateDefault(new Uri(targetUrl));
using (var response = (HttpWebResponse)req.GetResponse())
{
using (var sr = new StreamReader(response.GetResponseStream()))
{
data= sr.ReadToEnd();
}
}
None of this test were successful.
Try to use Fiddler or some integrated network analyzer inside Chrome/FF browsers to see the HTTPS requests/responses and their headers.
The latency was due to a certificate validation timeout. One of the issuer in the chain was not correctly deployed in the client server.
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!