getProperty/setProperty: how to determine whether 'property' is proxy-independent or not? #90
Comments
|
Properties are mostly undefined right now, but I'm going to be working on finishing the ABI doc over the next week or two. Why do you ask, though? Are you working on another SDK or proxy implementation? |
|
Thanks for reply. I am working on the MOSN project, another proxy for service mesh written in Golang. |
|
Nice! In that case, you might want to wait until the updated ABI is finalized (see: proxy-wasm/spec#1), since it's undergoing a heavy rewrite. |
|
Properties are intentionally open-ended since we don't want to bump ABI every time we need something extra. |
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 11, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 11, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 11, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 11, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 12, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 12, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 13, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 14, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
hishamhm
added a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 14, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
thibaultcha
pushed a commit
to Kong/ngx_wasm_module
that referenced
this issue
Jul 15, 2022
Implements the `get_property` call for the proxy-wasm SDK. The actual properties themselves are not listed by the proxy-wasm specification, so they seem to be proxy-specific. In this initial iteration, the only properties implemented are Nginx variables, obtained using the Nginx API via `ngx_http_get_variable` and hence exposed in the `ngx.http.*` property path. The ABI for property path values (that is, how they should be parsed by a host implementation) is not specified in the proxy-wasm spec docs either, so I have followed an implementation compatible with the input produced by the proxy-wasm-rust-sdk, which expects from the user a path as a vector of strings (`vec!["ngx", "http", "pid"]`) and produces a byte string to the host by joining them using `\0` bytes. With regard to property support, we could mimic the support for many Envoy attributes which are exposed via `get_property` by mapping them to the equivalent Nginx data. The list is available here: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/attributes.html?highlight=attributes However, the future of `get_property` and `set_property` is currently put into question: they are not included in the vNEXT docs, at least as of their state in 2020: see https://github.com/proxy-wasm/spec/pull/1/files#r472951567 — "I've dropped `{get,set}_property` from this iteration, since the current implementation is not really portable (it's an opaque pass-through to CEL), and I wanted to get a consensus on this MVP first... but we should definitely add something that can be standardized in its place as soon as this is merged.". More info about the current lack of standardization of properties here: proxy-wasm/proxy-wasm-cpp-host#90 The Envoy properties seem to be the "de facto" properties for proxy-wasm and which properties are proxy-specific or proxy-independent are ill-defined (they just map to the Envoy internals), but on our side, we start from a clean slate by using the `ngx` namespace for entries that map 1-to-1 to Nginx values.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
According to the comment, some properties likes "plugin_root_id" might be proxy-independent and some may not
but the function signature of getProperty and setProperty does not provide enough information to determine that
The text was updated successfully, but these errors were encountered: