PaperMC snapshots repository returns corrupt artifacts

Expected behavior

PaperMC's repositories, maven-public, maven-releases, and maven-snapshots return, or redirect to a page that returns, HTTP code 404 when the artifact is not found.

Observed/Actual behavior

The maven-snapshots repository returns 200 status codes for some artifacts that weren't found. This can cause Maven builds to fail with strange messages like "zip END header not found."

The behavior is thoroughly describable:

1. The repository returns HTTP 302 (redirect)
2. The redirect URL returns HTTP 200 (ok)
3. Maven follows the redirect URL, reads the 200 status code, and treats the page as a jar and downloads it.
4. Paper's JFrog Artifactory software therefore returns corrupt artifact data. Maven consumes this data, stumbles, and dies.

This is evidenced by log lines like this:

[WARNING] Could not validate integrity of download from https://repo.papermc.io/repository/maven-snapshots/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar: Checksum validation failed, no checksums available
[WARNING] Checksum validation failed, no checksums available from papermc-snapshots for https://repo.papermc.io/repository/maven-snapshots/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar
Downloaded from papermc-snapshots: https://repo.papermc.io/repository/maven-snapshots/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar (17 kB at 41 kB/s)

Clearly, adventure-api 5.1.0 is NOT 17 KB. That would be silly. However, this is the result of PaperMC's repository returning status code 200 despite the artifact being missing.

Steps/models to reproduce

1. Use the maven-snapshots repository.
2. Pick an artifact which doesn't come from that repository, e.g. adventure-api 5.1.0.
3. Run curl -I https://repo.papermc.io/repository/maven-snapshots/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar. Get HTTP status 302.
4. Run another curl on the redirect URL. curl -I https://artifactory.papermc.io/ui/native/snapshots/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar.
5. Result is HTTP status code 200, but actual document is clearly not a jar!

The artifactory page is in fact:

{
  "errors": [
    {
      "status": 404,
      "message": "Item snapshots:net/kyori/adventure-api/5.1.0 does not exist"
    }
  ]
}

Which is not valid jar data.

Plugin and Datapack List

NA

Paper version

NA

Other

Full log can be seen here: https://pastebin.com/FQNpBq2D

Reproduce the missing-artifact request with the curl commands and example URL in the issue, recording the redirect and final status codes. Then identify whether the maven-snapshots repository or its Artifactory configuration is managed in this project; done means missing artifacts return 404 rather than a 200 response containing non-JAR data.