Why is Golang http.ResponseWriter execution being

Question

I am trying to send a page response as soon as request is received, then process something, but I found the response does not get sent out "first" even though it is first in code sequence.In real life I have a page for uploading a excel sheet which gets saved into the database which takes time (50,0000+ rows) and would like to update to user progress. Here is a simplified example; (depending how much RAM you have you may need to add a couple zeros to counter to see result)

package main

import (
    "fmt"
    "net/http"
)

func writeAndCount(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Starting to count"))

    for i := 0; i < 1000000; i++ {

        if i%1000 == 0 {
            fmt.Println(i)
        }
    }
    w.Write([]byte("Finished counting"))

}

func main() {
    http.HandleFunc("/", writeAndCount)
    http.ListenAndServe(":8080", nil)

}

Answer 1

The original concept of the HTTP protocol is a simple request-response server-client computation model. There was no streaming or "continuous" client update support. It is (was) always the client who first contacted the server should it needed some kind of information.

Also since most web servers cache the response until it is fully ready (or a certain limit is reached–which is typically the buffer size), data you write (send) to the client won't be transmitted immediately.

Several techniques were "developed" to get around this "limitation" so that the server is able to notify the client about changes or progress, such as HTTP Long polling, HTTP Streaming, HTTP/2 Server Push or Websockets. You can read more about these in this answer: Is there a real server push over http?

So to achieve what you want, you have to step around the original "borders" of the HTTP protocol.

If you want to send data periodically, or stream data to the client, you have to tell this to the server. The easiest way is to check if the http.ResponseWriter handed to you implements the http.Flusher interface (using a type assertion), and if it does, calling its Flusher.Flush() method will send any buffered data to the client.

Using http.Flusher is only half of the solution. Since this is a non-standard usage of the HTTP protocol, usually client support is also needed to handle this properly.

First, you have to let the client know about the "streaming" nature of the response, by setting the ContentType=text/event-stream response header.

Next, to avoid clients caching the response, be sure to also set Cache-Control=no-cache.

And last, to let the client know that you might not send the response as a single unit (but rather as periodic updates or as a stream) and so that the client should keep the connection alive and wait for further data, set the Connection=keep-alive response header.

Once the response headers are set as the above, you may start your long work, and whenever you want to update the client about the progress, write some data and call Flusher.Flush().

Let's see a simple example that does everything "right":

func longHandler(w http.ResponseWriter, r *http.Request) {
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "Server does not support Flusher!",
            http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    start := time.Now()
    for rows, max := 0, 50*1000; rows < max; {
        time.Sleep(time.Second) // Simulating work...
        rows += 10 * 1000
        fmt.Fprintf(w, "Rows done: %d (%d%%), elapsed: %v\n",
            rows, rows*100/max, time.Since(start).Truncate(time.Millisecond))
        flusher.Flush()
    }
}

func main() {
    http.HandleFunc("/long", longHandler)
    panic(http.ListenAndServe("localhost:8080", nil))
}

Now if you open http://localhost:8080/long in your browser, you will see an output "growing" by every second:

Rows done: 10000 (20%), elapsed: 1s
Rows done: 20000 (40%), elapsed: 2s
Rows done: 30000 (60%), elapsed: 3s
Rows done: 40000 (80%), elapsed: 4.001s
Rows done: 50000 (100%), elapsed: 5.001s

Also note that when using SSE, you should "pack" updates into SSE frames, that is you should start them with "data:" prefix, and end each frame with 2 newline chars: "\n\n".

"Literature" and further reading / tutorials

Read more about Server-sent events on Wikipedia.

See a Golang HTML5 SSE example.

See Golang SSE server example with client codes using it.

See w3school.com's turorial on Server-Sent Events - One Way Messaging.

Answer 2

You can check if the ResponseWriter is a http.Flusher, and if so, force the flush to network:

if f, ok := w.(http.Flusher); ok {
    f.Flush()
}

However, bear in mind that this is a very unconventional HTTP handler. Streaming out progress messages to the response as if it were a terminal presents a few problems, particularly if the client is a web browser.

You might want to consider something more fitting with the nature of HTTP, such as returning a 202 Accepted response immediately, with a unique identifier the client can use to check on the status of processing using subsequent calls to your API.