What causes "Attribute bigger than maxSize allowed" in quarkusio/quarkus?

Increase the max size via DiskAttribute.setMaxSize(...)/DiskFileUpload.setMaxSize(...) or the factory's maxSize setting before parsing

quarkusio/quarkus · error · IllegalArgumentException

Attribute bigger than maxSize allowed

Error message

Attribute bigger than maxSize allowed

What it means

QuarkusMultipartResponseDataFactory.checkHttpDataSize calls Netty's HttpData.checkSize(length) and converts the resulting IOException (thrown when the incoming attribute/file exceeds the configured maxSize) into this IllegalArgumentException. The factory protects the client from unbounded memory/disk use while parsing a multipart response. The original size violation detail is discarded in this variant.

Source

Thrown at independent-projects/resteasy-reactive/client/runtime/src/main/java/org/jboss/resteasy/reactive/client/impl/multipart/QuarkusMultipartResponseDataFactory.java:203

            Attribute attribute = new MixedAttribute(name, definedSize, minSize, charset, baseDir, deleteOnExit);
            attribute.setMaxSize(maxSize);
            List<HttpData> list = getList(response);
            list.add(attribute);
            return attribute;
        }
        MemoryAttribute attribute = new MemoryAttribute(name, definedSize);
        attribute.setMaxSize(maxSize);
        return attribute;
    }

    /**
     * Utility method
     */
    private static void checkHttpDataSize(HttpData data) {
        try {
            data.checkSize(data.length());
        } catch (IOException ignored) {
            throw new IllegalArgumentException("Attribute bigger than maxSize allowed");
        }
    }

    public Attribute createAttribute(HttpClientResponse response, String name, String value) {
        if (useDisk) {
            Attribute attribute;
            try {
                attribute = new DiskAttribute(name, value, charset, baseDir, deleteOnExit);
                attribute.setMaxSize(maxSize);
            } catch (IOException e) {
                // revert to Mixed mode
                attribute = new MixedAttribute(name, value, minSize, charset, baseDir, deleteOnExit);
                attribute.setMaxSize(maxSize);
            }
            checkHttpDataSize(attribute);
            List<HttpData> list = getList(response);
            list.add(attribute);
            return attribute;

View on GitHub (pinned to e1c734241f)

Solutions

Increase the max size via DiskAttribute.setMaxSize(...)/DiskFileUpload.setMaxSize(...) or the factory's maxSize setting before parsing
Stream large files to disk (useDisk with a configured base directory) instead of keeping them in memory
If the server payload is unexpectedly large, fix the server or filter which parts the client requests

Example fix

// before
parts = factory.parseResponse(response); // default max size in effect
// after
DiskAttribute.setMaxSize(1024L * 1024L * 1024L); // 1GB
DiskFileUpload.setMaxSize(1024L * 1024L * 1024L);
parts = factory.parseResponse(response);

Defensive patterns

Strategy: validation

Validate before calling

DiskAttribute.setMaxSize(maxUploadBytes);
DiskFileUpload.setMaxSize(maxUploadBytes);
// or configure maxSize on the QuarkusMultipartResponseDataFactory before parsing

Try / catch

try {
    parts = parseMultipartResponse(response);
} catch (IllegalArgumentException e) {
    if (e.getMessage().contains("bigger than maxSize")) {
        throw new ResponseTooLargeException(e.getMessage(), e);
    }
    throw e;
}

Prevention

Set Netty DiskAttribute/DiskFileUpload max sizes to match the largest expected server payload
Check Content-Length before parsing large multipart responses
Use disk-backed storage for large file parts

When it happens

Trigger: Receiving a multipart response whose individual part (attribute or file) is larger than the maxSize configured on the QuarkusMultipartResponseDataFactory (default derived from Netty DiskAttribute/DiskFileUpload defaults unless overridden).

Common situations: Downloading large files via a multipart-consuming endpoint with the default max size still in effect; server sending bigger attachments than the client was configured for; unit tests with large generated payloads.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/a2de73bbf41c53c2. Report an issue: GitHub.