Fix superfluous response.WriteHeader call

[krissetto]

Fixes #47448

- What I did
Edited the endpoints for container stats and logs to avoid superfluous response.WriteHeader call being logged by the stdlib because we call WriteHeader() too many times.

- How I did it
Writing the response headers manually for streaming response writers instead of calling Flush().

OTEL instrumentation doesn't seem to wrap the Flush() func of http.ResponseWriter, so if we call Flush() on ioutils.WriteFlusher we directly hit the underlying stdlib implementation of Write()/WriteHeader() instead of the OTEL wrapped one.
If we then call Write() on the OTEL wrapper, after manually calling Flush() from ioutils, the wrapper will not know that headers have been written already and will therefore call the stdlib WriteHeaders() again, causing the warning log

- How to verify it

- Description for the changelog

Fixes the `superfluous response.WriteHeader call` warning log when executing `docker logs ...` or `docker compose stats`.

- A picture of a cute animal (not mandatory but encouraged)

[thaJeztah]

Trying to figure out how writing this here would prevent OTEL from trying to write a header again; wouldn't it still hit the "already wrote header" case?

moby/vendor/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/wrap.go

Lines 93 to 99 in f9dfd13

	func (w *respWriterWrapper) WriteHeader(statusCode int) {
	if !w.wroteHeader {
	w.wroteHeader = true
	w.statusCode = statusCode
	}
	w.ResponseWriter.WriteHeader(statusCode)
	}

[krissetto]

Trying to figure out how writing this here would prevent OTEL from trying to write a header again; wouldn't it still hit the "already wrote header" case?

moby/vendor/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/wrap.go

Lines 93 to 99 in f9dfd13

	func (w *respWriterWrapper) WriteHeader(statusCode int) {
	if !w.wroteHeader {
	w.wroteHeader = true
	w.statusCode = statusCode
	}
	w.ResponseWriter.WriteHeader(statusCode)
	}

Our Flusher calls Flush() on the stdlib implementation, not on the OTEL wrapper because it doesn't wrap the Flush() func. WriteHeader(), so if we call this here we are setting w.wroteHeader to true on the OTEL wrapper, so that subsequent calls to the OTEL wrapper's Write() func will NOT call the OTEL wrapper's WriteHeader() func.

---

example of current sitation:

calls to flusher.Flush();

• stdlib Flush() gets called by flusher.Flush();
• stdlib Write() gets called by stdlib Flush();
• stdlib WriteHeader() gets called by stdlibWrite()

calls to flusher.Write():

• OTEL wrapper Write() gets called by flusher.Write();
• OTEL wrapper WriteHeader() gets called by OTEL wrapper Write() - only when it hasn't been called before;
• stdlib WriteHeader() gets called by OTEL wrapper WriteHeader();
• stdlib Write() gets called by OTEL wrapper Write();
• flusher.Flush() gets called by flusher.Write();
• ... repeat above flow

Sorry for the verbosity, too much wrapping confusion here :)

[cpuguy83]

It seems like we either to need to manually instrument the streaming responses or provide a smarter writer implementation to the daemon so that the first flush calls WriteHeader explicitly.

[laurazard]

This seems like the cleanest/least-hacky fix for this, thanks!

[cpuguy83]

This is not the right place to handle this.

I'm also not sure how this fix the otel issue since the very first write to the stream would be writing out the response header.

[krissetto]

This is not the right place to handle this.
...
It seems like we either to need to manually instrument the streaming responses or provide a smarter writer implementation to the daemon so that the first flush calls WriteHeader explicitly.

Yeah i mostly agree with this, but there's another couple things to consider here:

• WriteFlusher is currently exported from our ioutils pkg, and used by a few other projects (https://grep.app/search?q=.NewWriteFlusher%28&filter[lang][0]=Go);
• We'd have to call Write() instead of WriteHeader() during Flush(), because of how the otel wrapper is written.

I have opened another draft pr yesterday, moving the current WriteFlusher impl and making a new internal one in /internal/writeflusher with these changes.

If we merge that, this PR can be closed as it'd be unnecessary, but I left it here in case we decide on a different strategy and we only want a quick fix for now.

[cpuguy83]

It seems like we either to need to manually instrument the streaming responses or provide a smarter writer implementation to the daemon so that the first flush calls WriteHeader explicitly.