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

Clarify that the syntax of instance_name is decided by the server #245

Merged
merged 2 commits into from
Apr 11, 2023

Conversation

Yannic
Copy link
Contributor

@Yannic Yannic commented Mar 8, 2023

I.e., servers may impose limitations on the instance_name they accept (e.g., that it does not contain slashes, newlines, or emojis).

I.e., servers may impose limitations on the `instance_name` they accept (e.g., that it does not contain slashes, newlines, or emojis).
@Yannic Yannic requested a review from bergsieker as a code owner March 8, 2023 20:58
// segments, used to distinguish between the various instances on the server,
// in a manner defined by the server. If it is the empty path, the leading
// slash is omitted, so that the `resource_name` becomes
// * `instance_name` is an identifier used to distinguish between the various
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I'm fine with with improving/relaxing the description slightly, could we please make sure the emphasis remains on the fact that it's path like?

Buildbarn, for example, does not allow you to provide an instance name beginning/ending with slashes, and containing multiple successive slashes. The reason being that it would otherwise be pretty hard to embed them in local file system paths and URLs.

(Maybe we should use this occasion to add "." and ".." to the list of forbidden path segments.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that we should forbid anything here, without asking around if it would break any existing implementations first. At the moment it's entirely server-implementation-defined, which seems to be working OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should probably look into restricting what's allowed (e.g., no // or / at the end or . or ..), but I agree with @mostynb that that'll need coordination with existing implementations and is out of scope for this PR.

My intent here is to make it more clear that it's up to the server to decide what is and is not allowed for that specific implementation. If a server wants [a-z0-9]+ here, it's free to reject anything that doesn't follow that syntax. If a server wants projects/123/instance/foo, so be it. Just like it is today.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced that this should be restricted to path-like strings (although I don't have a concrete idea of why someone would want to use something non-path-like). In any case, if we're going to restrict it further, I agree with @mostynb that we need to broadcast that change and check that we're not breaking anyone.

@Yannic
Copy link
Contributor Author

Yannic commented Mar 14, 2023

Rebased

@Yannic
Copy link
Contributor Author

Yannic commented Mar 15, 2023

@bergsieker PTAL

@Yannic
Copy link
Contributor Author

Yannic commented Mar 27, 2023

Ping?

// segments, used to distinguish between the various instances on the server,
// in a manner defined by the server. If it is the empty path, the leading
// slash is omitted, so that the `resource_name` becomes
// * `instance_name` is an identifier used to distinguish between the various
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced that this should be restricted to path-like strings (although I don't have a concrete idea of why someone would want to use something non-path-like). In any case, if we're going to restrict it further, I agree with @mostynb that we need to broadcast that change and check that we're not breaking anyone.

@bergsieker bergsieker merged commit 2871680 into bazelbuild:main Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants