net/http/fcgi: request context not canceled on aborted connection #71344

alexg-axis · 2025-01-20T14:18:59Z

Go version

go version go1.23.4 darwin/amd64

Output of `go env` in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/user/Library/Caches/go-build'
GOENV='/Users/user/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/user/go/pkg/mod'
GOOS='darwin'
GOPATH='/Users/user/go'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/Cellar/go/1.23.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/Cellar/go/1.23.4/libexec/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.23.4'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/user/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/Users/user/Development/temp/go-build2053259560=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Start an FCGI server.

listener, err := net.Listen("tcp", ":0")
defer listener.Close()

fcgi.Serve(listener, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
  // Emulate some slow operation, waiting for the context to cancel
  <-r.Context().Done()
  fmt.Println("Done with slow operation")
}))

Using an FCGI client, or a reverse proxy like Apache with FCGI support, issue a request to the server and then close the request. Unfortunately the code for this can get quite verbose as the package only implements the server parts and I'm not sure it provides much context in this case.

What did you see happen?

The string Done with slow operation is never printed as the context is never canceled.

What did you expect to see?

According to the documentation on the http request's context field, the context should be set and canceled when the connection closes or the server closes. As I haven't found any documentation in the fcgi package stating otherwise, I expect the same to be true.

From what I can tell, the issue comes from the fcgi package never setting a context that corresponds to the incoming connection. It relies on the default context.Background() returned by http.Request.Context if it's nil.

go/src/net/http/fcgi/child.go

Lines 292 to 302 in 40b3c0e

    
           httpReq, err := cgi.RequestFromMap(req.params) 
        
           if err != nil { 
        
           	// there was an error reading the request 
        
           	r.WriteHeader(http.StatusInternalServerError) 
        
           	c.conn.writeRecord(typeStderr, req.reqId, []byte(err.Error())) 
        
           } else { 
        
           	httpReq.Body = body 
        
           	withoutUsedEnvVars := filterOutUsedEnvVars(req.params) 
        
           	envVarCtx := context.WithValue(httpReq.Context(), envVarsContextKey{}, withoutUsedEnvVars) 
        
           	httpReq = httpReq.WithContext(envVarCtx) 
        
           	c.handler.ServeHTTP(r, httpReq)

This makes the fcgi package difficult to use when web clients are involved as there's seemingly no way to react on aborted / closed requests, making it difficult to stop ongoing work.

The text was updated successfully, but these errors were encountered:

gabyhelp · 2025-01-20T15:03:25Z

Related Issues

net/http: potential DOS: request context not cancelled if a client sends one byte after ServeHTTP starts #37145 (closed)
net/http: context isn't canceled on client disconnection #20668 (closed)
net/http/httputil: ReverseProxy gives "context canceled" message when client disappears #20071
net/http: Request.Context() canceled on Server.ReadTimeout #18447 (closed)
net/http: get-request with wrong content-length header breaks context #68571 (closed)
net/http: Request context is not canceled when `Server.WriteTimeout` is reached #59602
net/http: requests sometimes sent even when context is already canceled #25852 (closed)
net/http: Request not cancelled when body is not read #23262
net/http: request context cancelled on readtimeout, persists across connection reuse #70834
Go http context not able to capture cancellation signal when request has body (curl, postman) #33339 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

seankhliao · 2025-01-20T19:09:40Z

I suppose it can be wired up to FCGI_ABORT_REQUEST, but is there a server implementation that supports it? nginx apparently doesn't.

alexg-axis · 2025-01-21T10:07:09Z

That would only help the case of graceful shutdowns (which I can see as a feature request). It will not solve the issue of a connection getting killed, be it by a user's client or a reverse proxy. That is the issue I'm seeing as a bug - the context has no correlation to the request or underlying transport.

seankhliao · 2025-01-21T10:35:33Z

FastCGI multiplexes multiple client->proxy connections to fewer proxy->fastcgi connections.
If the proxy never informs the fastcgi application that the client->proxy connection was terminated (with the aborted message), then the fastcgi application won't know about it, since it's not tied to the lifetime of the connection between the proxy->fastcgi

alexg-axis · 2025-01-21T12:23:02Z

Thanks for the quick response. There would still be an issue with the proxy shutting down, right? Also, as far as I can tell, it isn't mandatory to multiplex requests, so non-multiplexed connections getting killed is still an issue. But I think you're right in that it won't help solve the case when an end-user kills a request when using a multiplexing reverse proxy, that would probably require FCGI_ABORT_REQUEST.

seankhliao · 2025-01-21T18:46:40Z

While it is possible for the proxy to open a new connection per client connection, I believe none of them will do so as then fastcgi would be pointless. Multiplexing is an inherent part of the protocol, requests sent/received are framed by unique request IDs over the underlying connection.

alexg-axis · 2025-01-22T08:09:04Z

From what I can gather nginx doesn't support multiplexing. It doesn't seem to be supported by mod_fastcgi or mod_proxy_fcgi either. Lighttpd doesn't support multiplexing either. Granted, a lot of search results are rather old and things might have changed. HAProxy does support multiplexing.

Nginx can be instructed to keep a connection alive, though. As can Apache. But none of them use it as a default behavior as far as I can tell.

I'd therefore argue that closing connections is a valid and common use case of FCGI and as the fcgi package doesn't document it as a limitation and as it reuses the http package's request type that does document the expectations of the context, this is is an issue.

alexg-axis · 2025-04-14T14:25:55Z

@seankhliao Have you had the chance to reconsider this issue?

alexg-axis changed the title ~~net/http/fcgi: Request context not canceled when peer connection is closed~~ net/http/fcgi: Request context never canceled (uses context.Background) Jan 20, 2025

gabyhelp added the BugReport label Jan 20, 2025

seankhliao changed the title ~~net/http/fcgi: Request context never canceled (uses context.Background)~~ net/http/fcgi: request context not canceled on aborted connection Jan 20, 2025

seankhliao added the NeedsInvestigation label Jan 20, 2025

seankhliao added the FeatureRequest label Jan 20, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net/http/fcgi: request context not canceled on aborted connection #71344

net/http/fcgi: request context not canceled on aborted connection #71344

alexg-axis commented Jan 20, 2025 •

edited

Loading

gabyhelp commented Jan 20, 2025

seankhliao commented Jan 20, 2025

alexg-axis commented Jan 21, 2025

seankhliao commented Jan 21, 2025

alexg-axis commented Jan 21, 2025

seankhliao commented Jan 21, 2025

alexg-axis commented Jan 22, 2025

alexg-axis commented Apr 14, 2025

net/http/fcgi: request context not canceled on aborted connection #71344

net/http/fcgi: request context not canceled on aborted connection #71344

Comments

alexg-axis commented Jan 20, 2025 • edited Loading

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

gabyhelp commented Jan 20, 2025

seankhliao commented Jan 20, 2025

alexg-axis commented Jan 21, 2025

seankhliao commented Jan 21, 2025

alexg-axis commented Jan 21, 2025

seankhliao commented Jan 21, 2025

alexg-axis commented Jan 22, 2025

alexg-axis commented Apr 14, 2025

alexg-axis commented Jan 20, 2025 •

edited

Loading

Output of `go env` in your module/workspace: