Why is Golang http.ResponseWriter execution being delayed?

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)

}

Markova

If you are using the default http.ResponseWriter, you can try Flush(): golang.org/pkg/net/http/#Flusher – Pessimism

related #19292613 – Katha

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.

Larger

Thanks for your really detailed answer, I have tried your solution but to me it seems it is only flushing once its finished the loop as it displays all Rows done: messages at once, rather than every 10,000 row count, if you increase time.Sleep to 10 * time.Second this is more noticable. – Markova

@Markova To me it works as expected. What client / browser do you use? – Larger

I use Chrome, and tested now on Firefox as well, both print all messages in one go after a delay. – Markova

@Markova Did you use the exact code I posted (and nothing more)? I've also tested it with curl, and I see continuous update at the client side. – Larger

I copied exactly the code on first try then changed the line time.Sleep(time.Second) // Simulating work... to time.Sleep(10 * time.Second) // Simulating work... to exaggerate delay as mentioned in my first comment. Just checked in console it does show but not on rendered page, now I need to work out why. Thanks for all your help. This was my first post. – Markova

@Markova It also works for me if I change the sleep to 10 seconds; then I see a new line appearing in the browser window in every 10 seconds, respectively. – Larger

I am behind a sophos firewall thats making the problems on browser display link – Markova

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.

Headsman

If I understand correctly flush is for updating a response, but I have a problem that even the initial response does not execute immediately therefore w.WriteHeader(http.StatusAccepted) would still be delayed. – Markova

The writer buffers whatever you write to it. Flush causes it to send what's in the buffer to the client before it would do so automatically. – Headsman

@Markova If the response header was not already written to the network, then Flush will write the response header (including the status set with w.WriteHeader) with any buffered response body data. – Drabble

In Go 1.20 or later, use ResponseController.Flush instead of the type assertion shown in this answer. – Drabble