Tunnel::call in hyper-util 0.1.20 dials a CONNECT target that names no port on 443 whatever the
scheme: tunnel.rs:146 hardcodes the fallback (unwrap_or(443)), and there is no knob to change it.
The direct path disagrees, because HttpConnector applies the scheme default, so a portless
http://host reaches port 80 without a proxy and port 443 through one. Nothing upstream covers this;
hyperium/hyper-util#300 is the separate split-read defect.
This repo pins the defect rather than working around it: the armonik-transport README's "Known
issues" section carries the bullet, and the tripwire test
known_issue_a_portless_http_target_is_dialled_on_443_not_80 in tests/upstream_tunnel.rs turns red
the day a hyper-util release changes the default. No fix in this crate: the code is upstream's, and
ArmoniK deployments always name a port, so the case is unreachable in practice.
Done when a hyper-util release applies the scheme default. Then delete the tripwire and the README
bullet.
Tunnel::callin hyper-util 0.1.20 dials aCONNECTtarget that names no port on 443 whatever thescheme:
tunnel.rs:146hardcodes the fallback (unwrap_or(443)), and there is no knob to change it.The direct path disagrees, because
HttpConnectorapplies the scheme default, so a portlesshttp://hostreaches port 80 without a proxy and port 443 through one. Nothing upstream covers this;hyperium/hyper-util#300 is the separate split-read defect.
This repo pins the defect rather than working around it: the
armonik-transportREADME's "Knownissues" section carries the bullet, and the tripwire test
known_issue_a_portless_http_target_is_dialled_on_443_not_80intests/upstream_tunnel.rsturns redthe day a hyper-util release changes the default. No fix in this crate: the code is upstream's, and
ArmoniK deployments always name a port, so the case is unreachable in practice.
Done when a hyper-util release applies the scheme default. Then delete the tripwire and the README
bullet.