Istio 1.1.11 carries HTTP/1.0 support into the ingress gateway
The July patch closes a gap between sidecar and ingress protocol configuration. Pilot now passes the HTTP/1.0 acceptance option into gateway connection managers when the compatibility mode is enabled.
Supporting a protocol between pods does not establish that the same request can enter through a gateway. The Istio 1.1.11 release on July 3 addresses that gap for HTTP/1.0. Its patch adds the ability to enable HTTP/1.0 acceptance at the ingress gateway, completing a configuration path that already existed for other proxies. The change is small, but the original report shows a precise difference between internal and external traffic.
In issue 13085, the reporter describes enabling PILOT_HTTP10=1 and observing HTTP/1.0 requests working between pods. Generated configuration contained accept_http_10: true. The ingress gateway did not receive the equivalent setting, and the external request returned an HTTP 426 Upgrade Required response from istio-envoy. This identified gateway configuration propagation as the missing behavior.
I consider this a useful example of why operating a mesh requires checking the proxy that actually handles a request. A control-plane option can be understood correctly while still reaching only some of its intended consumers. Internal success and gateway rejection can coexist because different configuration-generation paths produce their listeners.
Pilot adds the option to gateway connection managers
The tagged patch from 1.1.10 to 1.1.11 changes the gateway HTTP filter-chain construction. It creates HTTP/1 protocol options and enables AcceptHttp_10 when either Pilot's global HTTP/1.0 flag is enabled or the proxy's HTTP10 metadata equals 1. The resulting options are attached to the gateway connection manager.
The same options are connected in both branches shown in the patch, covering the function's plaintext and HTTPS processing. This is configuration of HTTP acceptance at the gateway. It does not replace the routing rules that determine which service handles an accepted request. Protocol acceptance and destination selection remain different stages of handling traffic.
The core condition is short enough to show directly. This is an excerpt from the released implementation, not a complete program.
if pilot.HTTP10 || node.Metadata[model.NodeMetadataHTTP10] == "1" {
httpProtoOpts.AcceptHttp_10 = true
}
The two inputs explain how the generator decides to enable the compatibility mode. A global Pilot setting can request the behavior, while proxy metadata can identify it for a particular proxy. The patch supplies the missing connection from that decision into gateway protocol options. It therefore closes the issue without requiring a new application-level traffic rule.
Enabled support is different from a new default
The release notes say the change adds an ability to enable HTTP/1.0. The implementation likewise uses an explicit condition before setting the acceptance option. Neither source describes unconditional acceptance of HTTP/1.0 on every gateway after the upgrade. An operator needs to distinguish installation of the supporting code from configuration that selects its behavior.
The metadata definition in the 1.1.11 source names the metadata key HTTP10 and says 1 enables it. Its comments describe the setting as alpha in the 1.1 series and subject to feedback-driven change. That maturity qualification is relevant even though this patch fixes a practical compatibility problem. The option exists without becoming a stable long-term configuration promise.
For a user affected by the original report, the important result is consistency between the chosen compatibility setting and the gateway's generated listener. A sidecar accepting the request was evidence about that sidecar. It was not evidence about the separate ingress listener. The patch makes the gateway generator honor the selection as well.
The test checks the generated contract
The patch adds a gateway filter-chain test using a proxy whose HTTP10 metadata is 1. Its expected result includes HTTP/1 protocol options with acceptance enabled in the connection manager. This is a focused check of the control-plane output that was missing. It directly connects the input metadata with the configuration required by Envoy.
That test does not claim to exercise every application behind the gateway. It checks the generator's responsibility in the chain. The original user report supplies the observable failure, while the patch and its test identify the configuration field needed to resolve that failure. Together they explain what changes in the maintenance release. The test compares the returned filter-chain options with the complete expected structure through deep equality. That includes the connection manager's protocol options, so merely accepting the metadata without placing it in the generated result would fail the comparison.
I value this kind of narrow compatibility repair because it makes the operational outcome understandable. Existing HTTP/1.0 clients can use a gateway configured to accept them, while the routing and policy configuration still determine their destination and access. The July patch brings the gateway's generated protocol setting into agreement with the explicitly enabled mode.