-
Notifications
You must be signed in to change notification settings - Fork 117
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
Conversation
I.e., servers may impose limitations on the `instance_name` they accept (e.g., that it does not contain slashes, newlines, or emojis).
// 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 |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Rebased |
@bergsieker PTAL |
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 |
There was a problem hiding this comment.
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.
I.e., servers may impose limitations on the
instance_name
they accept (e.g., that it does not contain slashes, newlines, or emojis).