How to do an HTTP duplex handler in Go?

I heard here that

> once you write anything in the response, the request body will be
> closed which prevents you from reading anything from it

If that is true, how can I write a proper duplex handler that is able to read from the request body, make some kind of transformation, and then write to the response body, in a streaming fashion just like people do in node.js ?

I ended up managing to do this with http.Hijacker.

After the request is made and the request headers are parsed, I can read from *http.Request.Body, then hijack the connection and write to it, at the same time, like this:

hj, ok := w.(http.Hijacker)
if !ok {
	http.Error(w, "hijacking not supported", 500)
	return
}

conn, bufrw, err := hj.Hijack()
if err != nil {
	http.Error(w, err.Error(), 500)
	return
}
defer conn.Close()

And then conn is a net.Conn which is the underlying TCP connection to the client, bufrw is a *bufio.ReadWriter, and to write the response without closing the body all I have to do is

_, err = bufrw.WriteString("HTTP/1.1 200 OK\n\n")
_, err = bufrw.WriteString("this")
_, err = bufrw.WriteString("is")
_, err = bufrw.WriteString("the")
_, err = bufrw.WriteString("response")
_, err = bufrw.WriteString("body")

And then I'm not sure about this but maybe someone can complete the answer, it's a good idea to flush the buffers down the connection once in a while with

err := bufrw.Flush()

> once you write anything in the response, the request body will be closed which prevents you from reading anything from it

March 2023: Go 1.22+ might include that feature, following the accepted proposal "net/http: add ResponseController.EnableFullDuplex"

> The net/http HTTP/1 server does not permit reading from an inbound request body after starting to write the response. (See the ResponseWriter.Write documentation).
>
> This limitation is because the server drains any unread portion of the request body before writing the response headers, to avoid deadlocking clients that attempt to write a complete request before reading the response. (See #15527 (comment) for more context.)
>
> I propose that we offer an opt-in mechanism to disable this behavior, permitting a server handler to write some or all of the response interleaved with reads from the request.

You now have CL 472636: net/http: support full-duplex HTTP/1 responses which starts implementing that:

// EnableFullDuplex indicates that the request handler will interleave reads from Request.Body
// with writes to the ResponseWriter.
//
// For HTTP/1 requests, the Go HTTP server by default consumes any unread portion of
// the request body before beginning to write the response, preventing handlers from
// concurrently reading from the request and writing the response.
// Calling EnableFullDuplex disables this behavior and permits handlers to continue to read
// from the request while concurrently writing the response.
//
// For HTTP/2 requests, the Go HTTP server always permits concurrent reads and responses.
func (c *ResponseController) EnableFullDuplex() error {
	rw := c.rw
	for {
		switch t := rw.(type) {
		case interface{ EnableFullDuplex() error }:
			return t.EnableFullDuplex()
		case rwUnwrapper:
			rw = t.Unwrap()
		default:
			return errNotSupported()
		}
	}
}

From the net/http docs you are referring to

> var ErrBodyReadAfterClose = errors.New("http: invalid Read on closed
> Body")
>
> ErrBodyReadAfterClose is returned when reading a Request or Response
> Body after the body has been closed. This typically happens when the
> body is read after an HTTP Handler calls WriteHeader or Write on its
> ResponseWriter

However I tried the code linked from the blog article you mentioned and it works fine under go 1.1.2 unless I write more than about 4k of data first in which case r.ParseForm() returns ErrBodyReadAfterClose.

So I think the answer is no, you can't do full duplex HTTP in go in general unless the responses are short (under 4k).

I would say that doing full duplex HTTP requests is unlikely to be a big benefit though as most clients won't attempt to read from the response until they have finished sending the request, so the most you'll win is the size of the TCP buffers in the client & server. A deadlock seems likely if these buffers are exceeded, eg

• client is sending request
• server is sending response
• servers buffers get full sending response
• server blocks
• server no longer reading clients request
• client buffers fill up
• client blocks
• deadlock