You are right Flush needs to write the header first, so the additional
header lines cannot be added by the server after Flush. The automatic
Content-Type might also not be written. A local proxy in front of your
server might be a simpler approach to measure full performance.
If the actual
Hi!
On Mon, Nov 20, 2023 at 10:51 PM Uli Kunitz wrote:
> You could convert the original ResponseWriter to a ResponseController and
> call Flush in your middleware before you measure the duration. Alternatively
> you can try to convert ResponseWriter to a http.Flusher and call Flush if the
>
You could convert the original ResponseWriter to a ResponseController and
call Flush in your middleware before you measure the duration.
Alternatively you can try to convert ResponseWriter to a http.Flusher and
call Flush if the conversion is successful.
The documentation says "Flush flushes
Hi!
On Mon, Nov 20, 2023 at 10:26 AM Duncan Harris wrote:
> Why do you care about buffering in Go vs the OS?
Just because I hope that in Go I might have a chance to know when they
are written out than in OS.
Mitar
--
https://mitar.tnode.com/
https://twitter.com/mitar_m
I would argue that it doesn't matter.
The buffers in the operating system can often substantially exceed the size
of those in the Go runtime.
Try using an artificially slow reader (e.g. curl --limit-rate) and you
should see.
Why do you care about buffering in Go vs the OS?
On Sunday, 19
