docs: document UPSTREAM_METADATA header variable#335
docs: document UPSTREAM_METADATA header variable#335mattklein123 merged 3 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
| The original protocol which is already added by Envoy as a | ||
| :ref:`x-forwarded-proto <config_http_conn_man_headers_x-forwarded-proto>` request header. | ||
|
|
||
| %UPSTREAM_METADATA(namespace, key[, key...])% |
There was a problem hiding this comment.
I kind of worry about parsing here being a big ugly when it comes to escaping spaces, quotes, dots etc. Do you have any thoughts on how we can specify this to allow cheap parsing? E.g. if the key list is a JSON list, we could reuse the JSON parser, etc.
There was a problem hiding this comment.
Maybe something like:
%UPSTREAM_METADATA("namespace", "foo", "bar")%
and then document that the strings are escaped as in JSON. And in envoy stuff some brackets around it and use the JSON parser?
There was a problem hiding this comment.
What about %UPSTREAM_METADATA(["namespace", "foo", "bar"])% ? Just actual JSON?
There was a problem hiding this comment.
Sure. Probably get better error messages that way.
| :ref:`x-forwarded-proto <config_http_conn_man_headers_x-forwarded-proto>` request header. | ||
|
|
||
| %UPSTREAM_METADATA(namespace, key[, key...])% | ||
| Populates the header with ref:`EDS endpoint metadata <envoy_api_file_api/eds.proto>` from the |
There was a problem hiding this comment.
We also have CDS metadata now that is an upstream concept. Do we want to include access to it in this header variable? Would we merge the metadatas together? We had this idea that the LDS/RDS metadata would all be merged before being made available to the user (at the RequestInfo level internally). I don't have a strong opinion on what it should look like, just raising these considerations.
There was a problem hiding this comment.
Ultimately, I think CDS metadata should get merged in, probably with EDS values taking precedence over CDS. It doesn't seem to have been plumbed through to ClusterInfo yet, though.
There was a problem hiding this comment.
IMO I would just log a follow up issue for CDS metadata, but I could go either way.
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
Modifies the Router::RequestInfoHeaderFormatter to support extracting string, numeric, and boolean values from the upstream host provided by AccessLog::RequestInfo. Modifies Router::HeaderParser to omit headers whose formatted value is an empty string. Docs Changes: envoyproxy/data-plane-api#335 Fixes #2148. Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
Provides documentation for the changes related to envoyproxy/envoy#2148.