You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gitlabURLRegex in internal/validators/utils.go only accepts exactly two path segments (owner/repo), so valid GitLab repository URLs using nested groups/subgroups (e.g. https://gitlab.com/myorg/team/subgroup/my-mcp-server) are rejected with invalid repository URL. Subgroups are a standard GitLab feature, and this blocks publishing servers whose source lives in a GitLab group hierarchy.
Fix
Change the regex from ^https?://(www\.)?gitlab\.com/[\w.-]+/[\w.-]+/?$ to ^https?://(www\.)?gitlab\.com/[\w.-]+(/[\w.-]+)+/?$.
Note this is slightly stricter than the [\w./-]+ variant suggested in the issue: it validates segment-by-segment, so URLs with empty path segments (gitlab.com/group//repo) stay rejected. The GitHub regex is unchanged (GitHub has no subgroups).
Testing
Added internal/validators/utils_test.go with table-driven cases for IsValidRepositoryURL: nested/deeply-nested subgroup URLs now pass; flat owner/repo, trailing slash, and www. cases keep passing; malformed URLs (empty segments, spaces, spoofed hosts, query strings, fragments, missing repo) stay rejected; GitHub behavior unchanged.
Added an end-to-end ValidateServerJSON case with a GitLab subgroup repository URL.
go test ./internal/validators/... green; gofmt/go vet clean; golangci-lint introduces no new issues.
Bug: gitlabURLRegex hard-codes exactly two path segments (owner/repo), so GitLab nested subgroups (gitlab.com/org/team/sub/repo) are rejected — blocks self-hosted registries whose source lives in a group hierarchy.
Fix: one regex, [\w.-]+/[\w.-]+ → [\w.-]+(/[\w.-]+)+.
Note vs the issue's suggestion: the issue proposed [\w./-]+, but putting / inside the char class would also accept empty segments (group//repo). The segment-by-segment form here stays strict on that. GitHub regex untouched (no subgroups there).
23 table-driven cases (nested + deeply-nested pass; flat/trailing-slash/www. still pass; empty-segment/spaces/spoofed-host/query/fragment still rejected) + an e2e ValidateServerJSON case. go test ./internal/validators/... green, gofmt/vet clean, no new golangci-lint findings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1359
Problem
gitlabURLRegexininternal/validators/utils.goonly accepts exactly two path segments (owner/repo), so valid GitLab repository URLs using nested groups/subgroups (e.g.https://gitlab.com/myorg/team/subgroup/my-mcp-server) are rejected withinvalid repository URL. Subgroups are a standard GitLab feature, and this blocks publishing servers whose source lives in a GitLab group hierarchy.Fix
Change the regex from
^https?://(www\.)?gitlab\.com/[\w.-]+/[\w.-]+/?$to^https?://(www\.)?gitlab\.com/[\w.-]+(/[\w.-]+)+/?$.Note this is slightly stricter than the
[\w./-]+variant suggested in the issue: it validates segment-by-segment, so URLs with empty path segments (gitlab.com/group//repo) stay rejected. The GitHub regex is unchanged (GitHub has no subgroups).Testing
internal/validators/utils_test.gowith table-driven cases forIsValidRepositoryURL: nested/deeply-nested subgroup URLs now pass; flatowner/repo, trailing slash, andwww.cases keep passing; malformed URLs (empty segments, spaces, spoofed hosts, query strings, fragments, missing repo) stay rejected; GitHub behavior unchanged.ValidateServerJSONcase with a GitLab subgroup repository URL.go test ./internal/validators/...green;gofmt/go vetclean;golangci-lintintroduces no new issues.