Will HTTP ResponseWriter's write function buffer in Go?

Question

Assume that we have a function handling an HTTP Request, something like:

func handler(w http.ResponseWriter,  r *http.Request) {
    w.Write([]byte("first piece of data"))
    // do something
    w.Write([]byte("second piece of data"))
}  

I'm wondering that if the first call to w.Write() is flushed to client or not?

If it is flushed, then we actually responses to clients twice, this is strange because how can we determine Content-Length before the second call to write?

If it is not flushed (say the data is buffered locally), then what if we write a huge amount of data at the first call? (will that stack overflow?)

Any explanation will be appreciated! :)

Answer 1

I'm wondering that if the first call to w.Write() is flushed to client or not?

net/http's default ResonseWriter has a (currently 4KB) large output buffer over the net.Conn it writes to. Additionally, the OS normally will buffer writes to a socket. So in most cases some kind of buffering takes place.

If it is flushed, then we actually responses to clients twice, this is strange because how can we determine Content-Length before the second call to write?

Well there's HTTP 1.1 which allows persistent connections. Such responses usually don't include a Content-Length header. Additionally, there's HTTP trailers.

If your client does not support HTTP 1.1 and persistent connections they will have some sort of read timeout, during this time you can write to the connection as many times as you like; it's one response.

This has more to do with the nature of TCP sockets and HTTP implementations than Go.

If it is not flushed (say the data is buffered locally), then what if we write a huge amount of data at the first call? (will that stack overflow?)

No, allocating a buffer on the stack makes no sense – the buffer's body will live on the heap. If you hit your per-process memory limit your application will panic "out of memory".

See also:

• How to turn off buffering on write() system call?
• *TCPConn.SetNoDelay

Edit to answer your question in the comments:

Chunked Transfer Encoding is part of the HTTP 1.1 specification and not supported in HTTP 1.0.

Edit to clarify:

As long as the total time it takes you to write both parts of your response does not exceed your client's read time out, and you don't specify a Content-Length header you just write your response and then close the connection. That's totally OK and not "hacky".