<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=325117) </details> <!--IssueSummary end--> Our current approach to terminating Git HTTP requests (when the client goes away for instance) is lazy: we try to copy stdout of e.g. git-upload-pack into the network socket that goes to the client (via NGINX!) and if that write fails, the copy operation fails, and we abort, killing the git-upload-pack process. If that copy operation gets stuck in limbo (perhaps because of an intermediate buffer that hides the fact that NGINX terminated the client connection to gitlab-workhorse) there is nothing in gitlab-workhorse that will kill the git-upload-pack process. It seems that this is not a hypothetical issue. https://gitlab.com/gitlab-com/infrastructure/issues/486#note_16197551 The go net/http server has a 'CloseNotifier' mechanism that may help us out here. It will be a little finnicky to pass this notifier down the call stack but I think it can be done. If we have that we can make the code that 'shells out' to git-upload-pack respond to a signal that the client went away. cc @pcarranza @ayufan