Sisk
Request with HttpClient to Sisk Server with SSL returns Bad Gateway #14
-
|
Hi, I'm using the Sisk Server in a .NET Console App and it is working perfect with HTTP connections (requests from Browser and also requests from .NET HttpClient). Now I also enabled SSL:
So if I call the same requests now, but instead of http:// and the http port using https:// and port 4646, the .NET HttpClient receives a Bad Gateway response from Sisk. While debugging I can verify that my route and return value is called at server side, so everything seems to be fine, but HttpClient is not receiving this, instead throwing the Bad Gateway exception. If I make the same request from any browser (Edge, Chrome, etc.) it is working fine too, so there is no Bad Gateway error. The content of the Bad Gateway response is: Do you have any ideas, why this happens? What special requirements are neccessary to get web request from HttpClient to Sisk over SSL work? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
I found out that it is a time problem. It looks like the SSL proxy has a timeout of just a few milliseconds. As soon as a method takes 1 second or more to process, for example, the Bad Gateway error is thrown straight away. If, however, the method only takes a few milliseconds, then there is no problem. You can test this easily with adding a Thread.Sleep(3000); in a route call on server side. Have you set the timeout extremely low for testing purposes? Can it be set higher from outside or do I have to wait for a new version? |
Beta Was this translation helpful? Give feedback.
-
|
In general, it seems that it is a problem associated with the HttpSerializer, specifically in the part that reads the server's response. If you look at the source code of SslProxy, you will see that the correct timeouts are being set on the NetworkStream streams, but they are not working. So, I believe it is an issue of asynchronicity in reading the proxy's response. I have put the SslProxy project on hold for a bit; lately, I have been short on time, and it is complicated to write the HTTP/1.1 listener implementation from scratch, considering that .NET does not provide anything ready other than SslStream and the plain HttpListener for HTTP only. In the documentation, I mentioned alternatives to use Sisk with SSL that are more stable than SslProxy. These alternatives are only for development, and I do not recommend using them in production. There is an article discussing how to deploy a Sisk application in production. If you would like to work on SslProxy as well, your help would be very welcome. I want to continue working on this extension to see if it will be something viable to maintain in the future. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, I've found the bug and commited the fix here. Basically, TcpClient.ReceiveTimeout expects a timeout in milliseconds. I were setting it in seconds instead milliseconds. Could you test to see if it solves it? |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! It is working now! Sometimes it's just the little things 😀 |
Beta Was this translation helpful? Give feedback.
-
|
Nice! I'm glad we fixed this. I'm closing this issue now. Thank you. |
Beta Was this translation helpful? Give feedback.
By the way, I've found the bug and commited the fix here.
Basically, TcpClient.ReceiveTimeout expects a timeout in milliseconds. I were setting it in seconds instead milliseconds.
Could you test to see if it solves it?