theonedev/onedev · error · HttpResponseAwareException

Checksum exceeds maximum size: ${MAX_CHECKSUM_LEN}

Error message

Checksum exceeds maximum size: ${MAX_CHECKSUM_LEN}

What it means

During uploadBlob, when the uploaded file name is a checksum file (e.g. artifact.jar.sha1), the handler copies the body into memory with copyWithLimit/is capped at MAX_CHECKSUM_LEN to read the checksum. If the stream is longer than MAX_CHECKSUM_LEN, copy returns -1 and the handler rejects the upload with HTTP 406, since a legitimate checksum file is tiny.

Source

Thrown at server-plugin/server-plugin-pack-maven/src/main/java/io/onedev/server/plugin/pack/maven/MavenPackHandler.java:348

		}
	}
	
	private void uploadBlob(HttpServletRequest request, HttpServletResponse response,
							Long projectId, Long buildId, String groupId, @Nullable String artifactId, 
							@Nullable String version, String fileName) {
		sessionService.run(() -> {
			checkProject(projectId, true);
		});
		try (var is = request.getInputStream()) {
			var lockName = "update-pack:" + projectId + ":" + TYPE + ":" + groupId;
			if (artifactId != null && version != null)
				lockName += ":" + artifactId + ":" + version;
			var blobName = getBlobName(fileName);
			if (!blobName.equals(fileName)) { // checksum verification
				var baos = new ByteArrayOutputStream();
				var copied = copyWithMaxSize(is, baos, MAX_CHECKSUM_LEN);
				if (copied == -1)
					throw new HttpResponseAwareException(SC_NOT_ACCEPTABLE, "Checksum exceeds maximum size: " + MAX_CHECKSUM_LEN);
				var checksum = new String(baos.toByteArray(), UTF_8);
				LockUtils.run(lockName, () -> transactionService.run(() -> {
					var project = projectService.load(projectId);
					Pack pack = findPack(project, groupId, artifactId, version);
					if (pack != null) {
						MavenData data = (MavenData) pack.getData();
						var sha256BlobHash = data.getSha256BlobHashes().get(blobName);
						if (sha256BlobHash != null) {
							PackBlob packBlob;
							if ((packBlob = packBlobService.checkPackBlob(projectId, sha256BlobHash)) != null) {
								String blobHash;
								if (fileName.endsWith(EXT_SHA256))
									blobHash = sha256BlobHash;
								else
									blobHash = getNonSha256Hash(packBlob, fileName);
								if (blobHash.equals(checksum)) {
									packBlobReferenceService.createIfNotExist(pack, packBlob);
									response.setStatus(SC_OK);

View on GitHub (pinned to d44925c47c)

Solutions

  1. Check the upload path: the file you are uploading is being treated as a checksum file; correct the URL/file name so the real artifact gets the artifact path.
  2. Upload the actual artifact first, then let the client upload its genuine (small) checksum file.
  3. If a proxy/build script rewrites paths, fix the rewriting so checksum files stay separate from binaries.

Example fix

// before — uploading binary under checksum name
curl -T app.jar "$URL/com/acme/app/1.0/app-1.0.jar.sha1"
// after
curl -T app.jar "$URL/com/acme/app/1.0/app-1.0.jar"
curl -T app.jar.sha1 "$URL/com/acme/app/1.0/app-1.0.jar.sha1"
Defensive patterns

Strategy: validation

Validate before calling

# Before upload, ensure the file you PUT with a checksum-suffixed name is actually small
FILE=app-1.0.jar.sha1
SIZE=$(stat -c%s "$FILE")
MAX=4096  # keep well under MAX_CHECKSUM_LEN
[ "$SIZE" -le "$MAX" ] || { echo "$FILE is $SIZE bytes — not a checksum file"; exit 1; }

Prevention

When it happens

Trigger: A client PUTs a file whose name looks like a checksum file (*.sha1, *.sha256, *.md5 — matched by getBlobName/verification logic) but whose body exceeds MAX_CHECKSUM_LEN bytes, usually because the actual artifact was uploaded under the checksum file name or a misconfigured client streams the wrong file.

Common situations: Misconfigured Maven deploy uploading artifact under wrong path; hand-crafted REST upload naming the binary file with a .sha1/.md5 suffix; proxy mangling upload paths so the jar lands on the checksum URL.

Understand the failure class

Background: "File too large" / "file size exceeds limit" errors: why libraries cap file sizes and how to fix them — this error's family across 46 libraries.

Related errors


AI-assisted analysis of theonedev/onedev@d44925c47c (2026-09-06). Data as JSON: /api/errors/8caeef6e1bfdda3f. Report an issue: GitHub.