[feature request] Fault-in-standard-out option on TE header at 1xx and 204

[lambdai]

#11458 and #10811 fixed the transfer-encoding: chunked behavior.

Unfortunately the runtime-key is controlling both upstream and downstream.

Zero down time cannot be achieved unless the entire Envoy are upgraded atomically.

Is it possible to provide an option to tolerate non-standard upstream response and provide standard TE?

See the ideal state here.
istio/istio#28450 (comment)

[lambdai]

CC @zuercher

[mattklein123]

cc @alyssawilk to advise

[alyssawilk]

I think it's less about upgrading atomically and more about updating the value of that flag atomically.

If atomic flag flips are problematic, I think it's plausible to break the runtime guards into upstream and downstream variants, and backport, given that Istio has done substantial work on stable releases. cc @PiotrSikora for that.

I'll definitely keep such things in mind for future data plane guards. cc @snowp @mattklein123 as the other folks who tend to handle data plane changes

[linsun]

subscribe

[hxn36]

Hi, any update on this? Will there be a feature to add those flags automatically through a configmap?

[alyssawilk]

I don't think anyone signed up to add a second flag. cc @zuercher

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

[howardjohn]

@lambdai I think we are still interested?

[Monkeyanator]

Friendly bump on this, think we're still interested.

From here it seems like the strict_1xx_and_204_response_headers is targeted for removal in 1.18.0? IIUC, if we removed the flag altogether without adding separate flags for upstream and downstream, there would be no way for old proxies using strict_1xx_and_204_response_headers=false to stay compatible with newer proxies?

[mattklein123]

cc @alyssawilk wdyt?

[alyssawilk]

Yeah, I think we ought to split them up.
@lambdai as this was first reported as an issue with istio would you be willing to (and have cycles to) do the split?

[zuercher]

I'll close the PR I just created (for #14650, because it referenced my PRs I thought it was just misnamed, fixed now). I'm on PTO starting tomorrow so I won't have time to look at this.

[lambdai]

@tbarrella Do you have the bandwidth for this?

[tbarrella]

I should be able to do this. I'm assuming we don't want to break what happens when strict_1xx_and_204_response_headers is true and the new flag is false, or (breakingly) change strict_1xx_and_204_response_headers to an enum. Is there any precedent for how Envoy would interpret two overlapping flags like this? i.e., with features strict_1xx_and_204_response_headers and accept_1xx_and_204_transfer_encoding_headers,

accept does nothing unless strict is true

	strict true	strict false
accept true	receive TE	send + receive TE
accept false	-	send + receive TE

vs.

accept only does something when strict is false (the flag name would have to be more like only_accept)

	strict true	strict false
accept true	-	receive TE
accept false	-	send + receive TE

vs.

strict does nothing if accept is true (the flag name would have to be more like only_accept)

	strict true	strict false
accept true	receive TE	receive TE
accept false	-	send + receive TE

The first option looks the most intuitive to me... @alyssawilk does that seem fine?

[alyssawilk]

I don't think we have precedent for this, so I'm game for anything which allows istio (and others) to roll out multi-level support. Keeping prior behavior with envoy.reloadable_features.strict_1xx_and_204_response_headers true is a nice to have, but I'm totally fine with say deleting that guard and replacing it with two new ones (for upstream / downstream) (permissive/strict), whatever makes sense.

[tbarrella]

Thank you! I think I'll split it into two distinct guards so that the behavior is less confusing.