Based on an example I found, http://weblog.west-wind.com/posts/2013/Sep/04/SelfHosting-SignalR-in-a-Windows-Service, I'm implementing a SignalR host server within a Windows Service.
It all works fine but if I try:
SignalR = WebApp.Start<SignalRStartup>("http://*:8080/");
I get an unhandled exception of type `
'System.UriFormatException'` occurred in System.dll
Additional information: Invalid URI: The hostname could not be parsed.
It works fine if I use
SignalR = WebApp.Start<SignalRStartup>("http://localhost:8080/");
Probably a dumb assumption but based on the article I took this from, I assumed the *:8080 syntax would work. My question is, have I missed something or was the article incorrect and this format won't work?
So, the + does work... (and yes, I feel dumb) During my testing I think only 1/2 the time I remembered to run as administrator, which lead to bad test results since it was failing because of trying to open the port, and not because of the address.
I got clued into this by reading the Owin/Katana source code linked by #DigitalD. Turns out that not only does it support the + syntax, there is a comment from the code saying it's assuming it...
http://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.Host.HttpListener/OwinHttpListener.cs
// Assume http(s)://+:9090/BasePath/, including the first path slash. May be empty. Must end with a slash.
Have you tried removing the port number from the URI?
try
http://localhost instead of http://localhost:8080
Related
I'm having an issue with what I've deduced is a content type with double quotes inside the single quotes when sending a request to Microsoft Graph. The "cool" part is that this only happens on my PC, and the exact same code with the exact same (databased) parameters runs fine on my colleague's PC.
The code is this:
var items = graph.Client
.Users[graph.AuthenticationOptions.UserName]
.Drive
.Root
.Children
.Request()
.GetAsync().Result
.Where(_itm => (typeof(T).ToString().Contains("Folder") ? _itm.Folder != null : _itm.File != null));
Everything works fine up to the .Result, but looking at the stack trace tells me that it's actually failing when sending the request with the following error:
Result Message:
Test method XXX.FileTransfer.Test.LibaryTests.MSGraphTests.OneDriveClient_FileNotNull threw exception:
System.AggregateException: One or more errors occurred. ---> Microsoft.Graph.ServiceException: Code: generalException
Message: An error occurred sending the request.
---> Azure.Identity.AuthenticationFailedException: ClientSecretCredential authentication failed: The character set provided in ContentType is invalid. Cannot read content as string using an invalid character set. ---> System.InvalidOperationException: The character set provided in ContentType is invalid. Cannot read content as string using an invalid character set. ---> System.ArgumentException: '"UTF-8"' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.
So, I have seen the part at the end about using Encoding.RegisterProvider, but it doesn't seem to work on .NET Framework 4.8 applications? Unless I just misunderstood the docs.
From a very extensive search through good old Google, I found a few references to this same error but sadly they were on different webservices, and rather annoyingly a couple of the companies behind the APIs were able to add the double quoted UTF-8 to their accepted response types.
I have checked the formatting of the keys, etc. and nothing seems out of place. I have even tried manually setting the content type in the headers of the request:
Microsoft.Graph.BaseRequest req = (Microsoft.Graph.BaseRequest)graph.Client
.Users[graph.AuthenticationOptions.UserName]
.Drive
.Root
.Children
.Request();
req.ContentType = "application/json; charset=utf-8";
req.Headers.Add(new HeaderOption("Accept", "application/json; charset=utf-8"));
var result = ((IDriveItemChildrenCollectionRequest)req).GetAsync().Result;
with no change in behaviour.
I'm very much at a loss of what to do here. Clearly there is something wrong with the configuration of my PC if it's sending this as the default content type, but I have no idea what. Any help would be greatly appreciated.
The behaviour is the same across the Sharepoint, OneDrive, and Mail APIs.
For some reason, this is now working.
I have changed nothing and now the problem does not occur. However!
The company I work for has had new VPN hardware and dropped the proxy server, and that seems to coincide with the MSGraph API now suddenly working. So my best answer for anyone who finds this question is to investigate whether your VPN or proxy server is modifying your content type in any way.
I will add this link for further reading, which explains the effect your proxy server may have on a HTTP Request: Do HTTP proxy servers modify request packets?
I am working on a .NET API that runs inside of a docker container. At some point it makes a call to a Python Flask API that is also running in a container.
var response = await httpClient.GetAsync("http://service-name:8000/actual/url")
which then produces the following error:
System.Net.Http.HttpRequestException: Resource temporarily unavailable
---> System.Net.Sockets.SocketException (11): Resource temporarily unavailable
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken
cancellationToken)
Has anyone had experience with this before and potentially knows a solution? I cant find much on the web about it at all. I have some seen some mentions of the issue potentially being related to the Flask API not using async methods but that doesnt make sense to me.
The Flask API produces the appropriate responses when accessed through a web browser or Postman using localhost:8000/actual/url and the container logs these responses. I have tried using the localhost URL in the .NET API but that does not work either.
If anymore information is needed please leave a comment and I will do my best to update the post quickly.
-- Christie
TLDR
A reason for the "Resource temporarily unavailable" error is when during name resolution the DNS Server responds with RCODE 2 (Server failure).
Long answer
I noticed the same behavior in a dotnet application running in a dotnet runtime alpine docker container. Here are the results of my investigation:
The error message "Resource temporarily unavailable" corresponds to the EAGAIN error code which gets returned by various functions from the C standard library. At first I suspected the connect() function because the C# stack trace indicates the error happening during the ConnectAsync() call of the c# socket. And indeed the EAGAIN error code appears in the man page of connect() with this description: "No more free local ports or insufficient entries in the routing cache".
I simulated a system with depleted local ports and noticed that a different exception gets thrown in that case, which rules out local port availability as a root cause for the original exception. Regarding the other mentioned cause in the man page it turns out that the routing cache was removed from Linux in 2012. commit
I started to look around for EAGAIN in the source of the musl C lib which is used in the dotnet runtime alpine docker container. After a while I finally noticed the gethostbyname2_r function which is used for resolving a domain name to an ip address via DNS. During System.Net.Sockets.Socket.ConnectAsync() the hostname is still a string and the name resolving happens in native code using the gethostbyname2_r function (or one of its variations).
The final question is: When does gethostbyname2_r return the EAGAIN error code? It's when the RCODE field in the header of the DNS Response has the value 2, which stands for "Server failure". source line 166
To verify this result I ran a simple mock DNS server which always returns the RCODE 2 in the DNS response. The resulting c# exception along with the stack trace matched the original exception exactly.
I've seen loads post on this forum about exchange API, but I've never found something like I have.
I' m trying to connect to Exchange using Exchange API in order to get all room's meetings.
My problem : Sometimes, it's working, I can connect and get all my informations. And 5m later, impossible to connect. I got Unauthorized.
It's not an error on code because it's working, I think it's a problem with exchange server, but I really don't know what it is...
On the next picture, there are traces.
On the left, when it's working, And the same 30m later (same identification, same room) which is not working.
http://hpics.li/2d9b216
If you have any ideas ? I really don't know what to do.
thanks (and sorry for my english !)
I notice that the working request comes from server A (look at the value of X-FEServer header), and the failing one comes from server B. Perhaps there is a configuration problem on server B.
thx for this.
I've done some tests : I've modified my host file in my computer. when the url is pointing to serveur A, it's working. When it's on the other server, not working. It's the same configuration on both, cannot find what's wrong. So I will conserve my actual host file (pointing always on serveur A).
I have a very simple Jabber client, which connects to Google Talk via our "Google Apps" domain account. The connect code is as simple as it gets:
jc.User = "chatbot#ourdomain.com";
jc.Server = "ourdomain.com";
jc.Password = "password";
jc.OnMessage += new MessageHandler(jc_OnMessage);
jc.OnDisconnect += jc_OnDisconnect;
jc.OnConnect += jc_OnConnect;
jc.Connect();
This has been running fine for a couple of years, but today it's suddenly stopped working: after the Connect(), I get the exception
A first chance exception of type 'netlib.Dns.DnsException' occurred in
netlib.Dns.dll
Additional information: DNS query fails
followed by
A first chance exception of type 'System.FormatException' occurred in
System.dll
Additional information: An invalid IP address was specified.
I know that Google have indicated that XMPP support is perhaps going away, but I can still connect to the account in question using a "proper" XMPP client.
I've tried changing the Server property to different settings, including:
xmpp-server.l.google.com
alt1.xmpp-server.l.google.com
talk.google.com
but all give the same result.
Does anyone know why this error is suddenly biting me, and what I can do to resolve it?
After literally hours of fiddling around, I've figured out that changing
jc.User = "chatbot#ourdomain.com";
to
jc.User = "chatbot";
solves the issue. Quite why it's worked for years, and has now suddenly stopped, is beyond me - I guess Google flipped a switch somewhere. Problem solved anyway, hopefully this will help someone else.
I am working with a program that is meant to publish to and read from an existing TIBCO EMS hosted on a server separate from the program. I have referenced the sample code provided with the TIBCO installation, resulting in a big chunk of the program. Here is the code snippet that I am having troubles with:
1 QueueConnectionFactory factory = new TIBCO.EMS.QueueConnectionFactory(serverUrl);
2 QueueConnection connection = factory.CreateQueueConnection(username,password);
3 QueueSession session = connection.CreateQueueSession(false, Session.AUTO_ACKNOWLEDGE);
When line 1 runs, it goes through alright. When line 2 runs, it goes through alright, however, the connection object is null, resulting in an error during line 3 where a NullReferenceException occurs.
I would have at least expected that line 2 would return some sort of error to show that the request timed out, the credentials were wrong, the url is inaccessible, or at least something to let me know what the issue is, but there is nothing like that, until it hits line 3.
Does it have to do with the configuration of my application? All I have done to get this working is include the TIBCO.EMS.dll as a reference and worked with the code from there.
Could it have something to do with the fact that I am connected to a VPN that requires a proxy? If so, how can I set up that proxy in my code?
Any help would be greatly appreciated. Thank you.
The issue was that I was using the wrong version of the .NET framework to work with the Tibco integration. The version I was using was farther along than the original.
It would think that your server URL is incorrect.
try different urls maybe like tcp://localhost:7222 (where localhost can be the IP/Name of the remote server)
install EMS locally on you workstation and see if you can connect to it. (Default admin with no password)