summaryrefslogtreecommitdiff
path: root/docker
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2020-08-24 11:35:01 -0400
committerMatthew Heon <matthew.heon@pm.me>2020-08-27 12:50:22 -0400
commit2ea9dac5e1d00b2820bd7156e3bea4b9fd98c1e6 (patch)
tree4251590df91107c2c0dafe12500bae05bc0c8fed /docker
parent7ccd821397d03ed545635de2a0b70a68ab4d46db (diff)
downloadpodman-2ea9dac5e1d00b2820bd7156e3bea4b9fd98c1e6.tar.gz
podman-2ea9dac5e1d00b2820bd7156e3bea4b9fd98c1e6.tar.bz2
podman-2ea9dac5e1d00b2820bd7156e3bea4b9fd98c1e6.zip
Send HTTP Hijack headers after successful attach
Our previous flow was to perform a hijack before passing a connection into Libpod, and then Libpod would attach to the container's attach socket and begin forwarding traffic. A problem emerges: we write the attach header as soon as the attach complete. As soon as we write the header, the client assumes that all is ready, and sends a Start request. This Start may be processed *before* we successfully finish attaching, causing us to lose output. The solution is to handle hijacking inside Libpod. Unfortunately, this requires a downright extensive refactor of the Attach and HTTP Exec StartAndAttach code. I think the result is an improvement in some places (a lot more errors will be handled with a proper HTTP error code, before the hijack occurs) but other parts, like the relocation of printing container logs, are just *bad*. Still, we need this fixed now to get CI back into good shape... Fixes #7195 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'docker')
0 files changed, 0 insertions, 0 deletions