CancellationToken when request gets aborted

[chylex]

Hi, is there any CancellationToken that gets cancelled when a browser aborts the request? Looking for an equivalent of ASP.NET Core's HttpContext.RequestAborted.

[CypherPotato]

Hello.

Unfortunately, there is no way to know if the connection was closed by the client until you try to write or read something. It's a current limitation of the HttpListener in the .NET Core implementation. Before, in the .NET Framework, there was a method called RegisterForDisconnectNotification that, through reflection, would make it possible to obtain a token for client disconnection, but apparently it was removed in the new implementations of .NET.

The client can disconnect and the internal stream continue active. As I mentioned, it's only possible to know if the client disconnected if you try to write or read that stream. Perhaps when the Cadente is set as the HTTP engine of Sisk, it will be possible to do this, because we will have access to the socket in its entirety, but for now, I don't know a way to make something that works this way on Windows, Linux, and OSX.

[chylex]

Cadente looks interesting, looking forward to it being production-ready. I already ran into a problem that seems to be exclusive to the Windows-specific implementation of HttpListener, so it will be nice to have an alternative with more consistent behavior between platforms.

[CypherPotato]

The windows-specific issue is related to the cancellation token? Maybe is an issue we can fix.

[chylex]

No, it seems to be related to the Windows-specific implementation of HttpListener - it's not able to listen on TCP ports 50000-50059, because they are somehow reserved in Windows. But if I run the same application under WSL where HttpListener uses a managed implementation, or if I use ASP.NET Core with Kestrel, it can listen on those ports without issues.

I have a desktop app with a built-in HTTP server via ASP.NET Core, but I've been trying to get rid of the ASP.NET Core dependency. I ended up finding this project and ported my HTTP server to Sisk, but my app happens to use ports starting at 50000 by default, so migrating would be a potentially breaking change, and I don't feel too great about potentially running into more issues caused by the two vastly different implementations of HttpListener.

There doesn't seem to be a way to force HttpListener to use the managed implementation on Windows, but if the plan is for Sisk to develop a custom managed implementation better than HttpListener, it should be an easy switch when it's ready.

[CypherPotato]

Are you using SSL? If so, Cadente is compatible as a SSL-Proxy for Sisk. You could listen with plain Sisk in any port and proxy the port 5000 through Cadente with SSL. Here's how you do it.

[chylex]

No, just plain HTTP.