Skip to content
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

Restrict stream_id Character Set for URL Parameter Compatibility #229

Open
thomasdarimont opened this issue Jan 27, 2025 · 2 comments
Open
Labels
v1Final Issues that must be fixed before we propose a spec to become a v1 final spec.

Comments

@thomasdarimont
Copy link
Contributor

thomasdarimont commented Jan 27, 2025

The current specification draft for the Shared Signals Framework defines stream_id as follows:

stream_id

Transmitter-Supplied, REQUIRED. A string that uniquely identifies the stream. A Transmitter MUST generate a unique ID for each of its non-deleted streams at the time of stream creation.

Since stream_id is intended to be used as a URL parameter, it is important to ensure that the character set is restricted to those that are safe for use in URLs. Without such a restriction, there is potential for issues with URL encoding/decoding or interoperability across systems.

Proposed Change

Add the following normative language to the specification:

The stream_id value MUST be limited to characters that are safe for use in URL parameters as defined in RFC3986.
Specifically, stream_id MUST conform to the "unreserved" character set defined in Section 2.3 of RFC 3986, which includes alphanumeric
characters (A-Z, a-z, 0-9), hyphen (-), period (.), underscore (_), and tilde (~).
A Transmitter MUST validate that all stream_id values conform to this character set.

This addition ensures that stream_id is URL-safe and can be used reliably as a URL parameter without requiring additional encoding or risk of invalid characters.

@tulshi tulshi added the v1Final Issues that must be fixed before we propose a spec to become a v1 final spec. label Feb 11, 2025
@tulshi
Copy link
Contributor

tulshi commented Feb 11, 2025

We could include this in v1, marked it as such, but we can discuss in today's call.

@FragLegs
Copy link
Contributor

If we want to maintain backwards compatibility, we need to say that this character set is RECOMMENDED

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1Final Issues that must be fixed before we propose a spec to become a v1 final spec.
Projects
None yet
Development

No branches or pull requests

3 participants