-
Notifications
You must be signed in to change notification settings - Fork 527
Exception at System.Net.Security.SslStreamInternal.EndRead when proxy request from Nginx to Kestrel through HTTPS #737
Comments
@yuwaMSFT Looks like a server side error, right... Was the response fine on the client side? |
@muratg Yes it's server side error. Response to client seemed to be fine. |
@yuwaMSFT What do you have in |
This is the Nginx configuration:
|
BTW, this is the configuration for the site serving as the reverse proxy. nginx.conf itself was the default one after installing nginx. |
What version of nginx are you using? |
nginx version: nginx/1.4.6 (Ubuntu) |
What happens if you add keep alive? Might be ngnix doing a close and the filter getting confused by it |
@benaadams That's what I was about to try 😄 |
There is also some oddness with ngnix, though not likely to be effecting this https://blog.cloudflare.com/the-curious-case-of-slow-downloads/ |
client should already send out request with keep-alive. Added the header for proxy in the site config: also set the ssl session cache in nginx.conf Even setting so, it seems nginx is still doing new connection for each https request from client. Probably it's because nginx needs to decrypt and re-encrypt for each request coming from client. Not sure if there is way to configure nginx to "cache" the proxy https connection... If client hits Kestrel server directly without nginx in front, it seems the first request would hit this exception, but not subsequent requests, unless browser does refresh. So this seems to be happening for each new HTTPS connection. Probably it's related to the HTTPS handshaking process? |
@benaadams Great article, useful knowledge for us in Kestrel too 👍 |
It's interesting that it doesn't repro on Windows. |
I can repro on Ubuntu with nginx 1.4.7, but it doesn't repro with nginx 1.8.1 (latest stable). |
Looks like an nginx issue, I'm inclined to close this. @muratg thoughts? |
Even without nginx, I am seeing this exception for the first request from client browser. |
However curl from the local machine, I don't see any error. |
Yeah, forget what I said earlier. It's not as consistent with the latest nginx, but after a few more requests I saw the exception again. |
corefx needs to implement ReadAsync and WriteAsync on SSLStream, I have no end of problems with the wrappers on BeginRead and EndRead #588 |
I didn't get to the bottom of it, but I was able to work around the problem by changing my nginx.conf from:
to:
with all else remaining the same. |
It seems like nginx is doing something funny in the connection, but I don't know what exactly (I'm not well versed in tcpdump, trying to learn some to get to the bottom of this). From the logs I can see that we get a FIN from nginx, but for some reason the code is stuck at KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel/Http/SocketInputExtensions.cs Line 39 in 50f187a
although we do consume all input. When KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel/Filter/StreamExtensions.cs Line 15 in f15471b
to return a faulted task, with the error coming from
because |
@yuwaMSFT What browser did you use? I'm not reproing trying to hit from Chrome on another machine. |
@CesarBS I am seeing this on both Chrome and IE on a Windows client machine. |
@CesarBS Also, the server is a Ubuntu box in Azure, the client is on Corp net... |
…#747). - If we're done before the client sends a FIN, force a FIN into the raw SocketInput so the task in FileteredStreamAdapter finishes gracefully and we dispose everything in proper order. - If there's an error while writing to a stream (like ObjectDisposedException), log it once and prevent further write attempts. This means the client closed the connection while we were still writing output. - This also fixes a bug related to the point above, where memory blocks were being leaked instead of returned to the pool (because we weren't catching the exception from Write()).
…et#737, aspnet#747). - If we're done before the client sends a FIN, force a FIN into the raw SocketInput so the task in FileteredStreamAdapter finishes gracefully and we dispose everything in proper order. - If there's an error while writing to a stream (like ObjectDisposedException), log it once and prevent further write attempts. This means the client closed the connection while we were still writing output. - This also fixes a bug related to the point above, where memory blocks were being leaked instead of returned to the pool (because we weren't catching the exception from Write()).
I was trying out the SSL feature on Kestrel. When putting Nginx in front to proxy request to Kestrel server via https, I always got the following exception for each client request:
\funfile\Scratch\yuwa\Failures\041216\kestrelhttps\kestrellog.log
When request from wget directly on local machine, I didn’t see such error. It seems something related to how Nginx terminates the https proxy connection. Is this a benign exception? If so, can we suppress it since it would fire for each https request proxied by Nginx.
BTW, I used the self-signed test cert (but I don’t think that’s the problem here).
The text was updated successfully, but these errors were encountered: