diff options
author | Matthew Heon <matthew.heon@pm.me> | 2020-08-24 11:35:01 -0400 |
---|---|---|
committer | Matthew Heon <matthew.heon@pm.me> | 2020-08-27 12:50:22 -0400 |
commit | 2ea9dac5e1d00b2820bd7156e3bea4b9fd98c1e6 (patch) | |
tree | 4251590df91107c2c0dafe12500bae05bc0c8fed /libpod/container_internal.go | |
parent | 7ccd821397d03ed545635de2a0b70a68ab4d46db (diff) | |
download | podman-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 'libpod/container_internal.go')
0 files changed, 0 insertions, 0 deletions