Before we land this though, I have a question for @mattklein123 / maintainers about scope, which is if folks are writing filter rules based on attribution context, would this mean we functionally ought to runtime guard response code detail changes, since now they can arguably affect L7 processing?

Hmm. Great call out. Yeah, this seems super fragile to me. I agree with Alyssa that if we are going to do something like this we now need to treat response code details as something that basically can't ever change. Personally I would really rather avoid that for a string. Is there some other way to accomplish what you are after without doing this change?

This is related to the discussion about attributing failure code to a filter. I think the outcome of that was that we should not be using response flags (since there are many filters), so this information only surfaces in the response code details.

Our filter intends to ship these details verbatim, so we are not going to try to parse it. But I can't rule out that some consuming system will try to parse the details.

This is related to the discussion about attributing failure code to a filter. I think the outcome of that was that we should not be using response flags (since there are many filters), so this information only surfaces in the response code details.

I thought we had thought about using extensible response flags? I guess extensible response flags are not better than string matching.

What if we had documentation/policy that response details are subject to change and should not be matched on? cc @alyssawilk for thoughts on this option.

Yeah, I think as long as we have warnings (maybe in config here as well as docs) to give us some leeway while things stabilize that'd be good.

Yeah, I think as long as we have warnings (maybe in config here as well as docs) to give us some leeway while things stabilize that'd be good.

+1, can you add this @kyessenov? I think adding this warning to the details docs that @alyssawilk just added would be good also. https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/response_code_details

/wait

Updated the doc.