Envoy: Framework for Richer Information in Responses

[junr03]

Title: Framework for Richer Information in Responses

Description:
Envoy contains a lot of rich information for every request and response. Some of this information is currently not easily accessible to service owners looking to understand the network topology, or debug problems. If this information were shared with trusted clients via response headers and body, it could provide for a richer debugging experience. Additionally, certain information could help downstream clients have more elegant behavior, e.g when receiving a response with x-envoy-overloaded, the client could back off.

There have been several issues in the community that speak to the same problem space. This issue tracks a framework to house setting up and configuring the richer information options, not necessarily all the potentially supported options. Some of the relevant issues are:

• https://github.com/envoyproxy/envoy/issues/3239
• https://github.com/envoyproxy/envoy/issues/1178
• https://github.com/envoyproxy/envoy/issues/4092
• https://github.com/envoyproxy/envoy/issues/2562

Relevant Links: @junr03 has written a design document that goes into a detailed proposal, please read and comment freely.

[junr03]

@vilobhmm do you mind adding details of the proposed functionality we discussed last week, and sharing a link to your document?

[vilobhmm]

@junr03 : Here is the doc link for Reverse Proxy Response Propagation to downstream

https://docs.google.com/document/d/1fMEK80KlpHcL4CwhniOupgQu4MDsxK4y4dKhthjjCMA/edit?usp=sharing

[cmluciano]

@vilobhmm Can you share that doc with the envoy-dev mailing list

[htuch]

To satisfy #1472 (which I'm going to close as dupe of this issue), we need to make sure that SSL failures have more fine grained error information reflected in responses. @vilobhmm can you amend your proposal to capture this? CC @ldemailly.

[vilobhmm]

@htuch : Will do. Thanks!

[vilobhmm]

@cmluciano : Here is the link. https://docs.google.com/document/d/1fMEK80KlpHcL4CwhniOupgQu4MDsxK4y4dKhthjjCMA/edit

Shared it via envoy-dev mailing list as well

[vilobhmm]

@htuch : Amended the design doc to capture the failure scenario reported in #1472

[vilobhmm]

CC @ldemailly

[stale[bot]]

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 other activity occurs. Thank you for your contributions.

[junr03]

@mergeconflict another data point for this specific feature request: https://blog.linkerd.io/2018/06/19/debugging-production-issues-with-linkerds-diagnostic-tracing/. I think that feature is pretty interesting, as it expands on the one hop idea.

I know that Lyft would find this incredibly useful.

Looking forward to chatting.

[mergeconflict]

I've started working on this for really real.
/assign @mergeconflict

[spenceral]

@mattklein123 would you be opposed to the addition of %RESPONSE_FLAGS% and %RESPONSE_CODE_DETAILS% as supported dynamic values for custom request/response headers?

I'd like to add them to get a cheap win here if it doesn't negatively impact the broader objective.

[mattklein123]

I'd like to add them to get a cheap win here if it doesn't negatively impact the broader objective.

Sure we are generally fine with adding new variables.

[mattklein123]

Fixed by #11007. Please open new issues with specific requests.