[paoValle]

MavenHandler.handleDownload answered 404 for a path parsePath could not read only when the path had four or more segments, so bar/1.0/bar-1.0.jar was proxied uncached: past the denylist, the pre-cache scan and the cooldown. The layout has no shorter path, so the count is gone, and TestMavenDottedGroupDirectoryNotCachedAsGroup now covers /bar/1.0/bar-1.0.jar and /bar-1.0.jar.

The suite is green with the race detector, and reverting the change makes both short paths return 200. A short file with an extension no Maven file has (/bar/1.0/bar-1.0.exe) is matched by isCoordinateFile and still proxied uncached — outside this issue, say if you want it here.

Closes #686.

Summary by CodeRabbit

• Bug Fixes
  • Requests using malformed or incomplete Maven artifact paths now consistently receive a 404 response instead of being forwarded upstream.
  • This behavior applies to both default and named repository routes, including paths too short to represent a valid Maven coordinate.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

MavenHandler.handleDownload now returns 404 for every path that parsePath cannot parse, regardless of path length. Tests cover short paths through the default and named repository routes and verify that they do not trigger upstream requests.

Changes: Maven path validation

Layer / File(s)	Summary
Reject unparseable paths and cover short routes internal/handler/maven.go, internal/handler/maven_repositories_test.go	The handler returns 404 for unparseable paths without checking path length. The test adds short paths and verifies 404 responses through both repository routes without additional upstream requests.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• git-pkgs/proxy#678: Changes the same Maven path decision and adds test coverage that this PR extends with short paths.

Suggested labels: bug

Suggested reviewers: simonchrz, andrew

Merge Risk: Minimal · up to c9ae9

Malformed short artifact paths now return 404 rather than being proxied. No merge-blocking risk was identified.

Security architecture risk: Low · up to c9ae9

The change narrows upstream access by rejecting malformed download paths earlier. It does not add privileges or change valid-download handling. Other uncached routes remain unchanged, and the available evidence does not establish complete protection across every Maven request path.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The effective change applies to requester-controlled paths classified as downloads through either repository route. It removes an upstream-fetch capability for short unparseable paths without adding upstream destinations or repository authority.

Security Findings and Attack Paths

• observed — A short path such as /bar/1.0/bar-1.0.exe remains outside download classification: .exe is not a recognized artifact extension, and isCoordinateFile rejects paths with fewer than four segments. It consequently retains the pre-existing uncached proxy route. This PR does not introduce or expand that behavior.

Trust Boundaries and Controls

• observed — The changed gate prevents newly rejected paths from falling into direct upstream relay. Valid coordinates still enter the shared denylist-controlled artifact flow; repository fallback remains conditional on an upstream-not-found error.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title names the main change: Maven paths too short to hold a coordinate now return 404. The raw summary says handleDownload returns 404 when parsePath yields an empty artifact, instead of proxying…
Linked Issues check		The change removes the segment-count guard in MavenHandler.handleDownload. Every path with an empty parsed artifact now returns 404, including paths too short for a Maven coordinate. The test adds `…
Out of Scope Changes check		The changes are limited to the #686 behavior and its automated test coverage. The production change prevents uncached proxying of unparseable Maven paths. The test changes cover the required short pat…
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…

Full details: Title check

Explanation

The title names the main change: Maven paths too short to hold a coordinate now return 404. The raw summary says handleDownload returns 404 when parsePath yields an empty artifact, instead of proxying short paths upstream. The objectives describe the same change, and the new test covers short paths. The title is specific and matches the changeset.

Full details: Linked Issues check

Explanation

The change removes the segment-count guard in MavenHandler.handleDownload. Every path with an empty parsed artifact now returns 404, including paths too short for a Maven coordinate. The test adds /bar/1.0/bar-1.0.jar and /bar-1.0.jar to the outside-layout cases and verifies the repository routes do not proxy them. This implements the coding requirements in #686.

Full details: Out of Scope Changes check

Explanation

The changes are limited to the #686 behavior and its automated test coverage. The production change prevents uncached proxying of unparseable Maven paths. The test changes cover the required short paths and existing repository routes. No unrelated change is shown.

Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 2 files.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: ef1239d9-c27b-4b5f-aee1-c4150b0b10e6

Commits

Reviewing files that changed from the base of the PR and between b6e71f4 and c9ae9f9.

Files selected for processing: 2

• internal/handler/maven.go
• internal/handler/maven_repositories_test.go

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[simonchrz]

This also turns some short checksum files that exist upstream into 404s. handleRequest sends every .sha1/.md5/... file to handleDownload, however short the path, and checksums of non-coordinate files can't be parsed either. Two that are on Maven Central:

• /archetype-catalog.xml.sha1 (and .md5)
• /.index/nexus-maven-repository-index.gz.sha1

On main both are proxied and return 200; with this change they return 404. I checked with a small test using mavenRepoUpstream and newMavenRepositoriesHandler.

One way to keep them: answer 404 for an unparsable path only when the file is an artifact (isArtifactFile), a checksum or signature of one (the name minus its checksum suffix passes isArtifactFile), or a coordinate file, and keep proxying the rest. A case for /archetype-catalog.xml.sha1 in the existing fallback test would cover it.