-
Notifications
You must be signed in to change notification settings - Fork 990
Align environment variable propagation names with POSIX and define normalization rules #4944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
7dca571
3edc7d0
842ebb8
c7a1196
757c39d
cc356d7
824012f
e82e744
eb57d2c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -77,12 +77,16 @@ configuration options to override the default environment variable. | |
|
|
||
| Environment variable names used for context propagation: | ||
|
|
||
| - SHOULD use uppercase letters, digits, and underscores for maximum | ||
| cross-platform compatibility | ||
| - MUST NOT include characters forbidden in environment variables per | ||
| platform-specific restrictions | ||
| - SHOULD follow naming conventions that align with the propagation format | ||
| specification they're implementing (e.g., `TRACEPARENT` for W3C trace context) | ||
| - MUST be normalized by: | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the consumer side, do we expect the consumer to support both uppercase and lowercase letters due to backward compatibility considerations, or we want the consumer to put a rigid bar and ignore things that are not using uppercase letters?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question. While handling this on the consumer side would align with Postel’s law (being liberal in what you accept), it introduces non-trivial complexity. In practice, it’s not just a matter of checking one alternative. We’d likely need to scan all environment variables and implement matching logic, which can become ambiguous and harder to reason about. From my perspective, it’s better to keep things simple and predictable by enforcing a consistent format (uppercase). If we later find real-world interoperability issues, we can still extend the consumer behavior in a backward-compatible way. So for now, I’d lean toward not adding this flexibility. It feels like YAGNI until we have concrete evidence that it’s needed.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 💯 |
||
| - uppercasing ASCII letters, | ||
| - replacing every character that is not an ASCII letter, digit, or underscore | ||
| (`_`) with an underscore (`_`), | ||
| - prefixing the name with an underscore (`_`) if it would otherwise start with | ||
| an ASCII digit. | ||
|
|
||
| > [!NOTE] | ||
| > This normalization is consistent with the environment variable naming rules | ||
| > defined in [POSIX.1-2024](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html). | ||
|
|
||
| #### Value Restrictions | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.