WIP do not merge: Dump HTTP operations

[mtrmac]

Quite often it has been useful to dump the full HTTP request and response headers, and sometimes fuill bodies, for debugging; we probably should make that possible either automatically at the “debug” log level, or when the user sets an option.

This is by no means a workable implementation for that, but I’ve written exactly this hack two or three times now, so right now I am at least recording it for posterity, expecting that rebasing it will be easier than rewriting it.

A real implementation should, I guess, wrap a http.RoundTripper or perhaps http.Client (or just http.Client.Do?), or perhaps using net/http/httptrace somehow.

[runcom]

Isn't this adding overhead to the command? I'm fine with this, just want to make sure we don't wait that much dumping req/res.

[rhatdan]

Any way to pass down a debug flag? Or just rebuild with a DEBUG Tag?

[mtrmac]

Isn't this adding overhead to the command?

Yes, and it completely clutters the debugging output. As I said

This is by no means a workable implementation

[mtrmac]

Any way to pass down a debug flag? Or just rebuild with a DEBUG Tag?

We have a types.SystemContext which can be used to pass down such flags, yes.

[rhatdan]

Just needs to have an update to the transports man page.

[mtrmac]

In addition to the previously-noted concerns about opt-in, this should almost certainly be reworked to become a http.RoundTripper, wrapper, so that all redirects are logged.

[kwilczynski]

This would be very useful for troubleshooting issues with access to remote registries. At the moment, I tend to opt for a set up with a transparent TLS proxy to snoop on this type of traffic, but having a log that exposes this type of data that can be easily enabled would be ideal.

[mtrmac]

For the record, Red Hat internal tracking: https://issues.redhat.com/browse/RHEL-36783