Hacker News Reader

Comment by jamespetercook | Hacker News Reader

Good point. Curious, does the server stop execution if you cancel a request? Or does the browser just discard the response when it receives it?

View on HN

I think in most cases in HTTP, the server does not "know" the browser has canceled and so continues to execute. I believe it builds the response but can no longer send it because the underlying TCP connection is closed. So server continues to execute, but response bits never make it back to the client computer. WebSockets and HTTP2 may change that story somewhat.

Edit: actually, I think I'm wrong here. Server does get a canceled socket, and can pass that to server code. In ASP.NET Core, this: https://andrewlock.net/using-cancellationtokens-in-asp-net-c...

I believe browsers will close the socket, not keep it open and then discard the response. Browsers certainly have no way to terminate server execution.

I was thinking that at first too, but the more I thought about it, maybe they do? For example if I GET /some/large/file.pdf, get 50% through, then cancel, the server is not going to _keep sending the bits_, is it? It should handle the socket closed stop reading the file, etc. With sever code, I've never seen IIS cancel ASP.NET code, but now I'm wondering if it doesn't make sense in some cases...

Actually, yeah, you can do it in ASP.NET, looks like: https://andrewlock.net/using-cancellationtokens-in-asp-net-c...

Reply on news.ycombinator.com