What causes "Copying MultiByteHttpData is not supported" in quarkusio/quarkus?

Avoid copying MultiByteHttpData; reuse the same instance or create a new one with the same content

quarkusio/quarkus · error · IllegalStateException

Copying MultiByteHttpData is not supported

Error message

Copying MultiByteHttpData is not supported

What it means

MultiByteHttpData represents multipart file-upload data buffered across multiple Netty ByteBufs in the RESTEasy Reactive client. The copy() method is part of the Netty InterfaceHttpData/FileUpload contract but is intentionally unimplemented here because copying multi-buffer content is not supported. Calling it always throws IllegalStateException.

Source

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

    @Override
    public boolean renameTo(File dest) {
        throw new IllegalStateException("Renaming destination file for MultiByteHttpData is not supported");
    }

    @Override
    public boolean isInMemory() {
        return true;
    }

    @Override
    public File getFile() {
        return null;
    }

    @Override
    public FileUpload copy() {
        throw new IllegalStateException("Copying MultiByteHttpData is not supported");
    }

    @Override
    public FileUpload duplicate() {
        throw new IllegalStateException("Duplicating MultiByteHttpData is not supported");
    }

    @Override
    public FileUpload retainedDuplicate() {
        throw new IllegalStateException("Duplicating MultiByteHttpData is not supported");
    }

    @Override
    public FileUpload replace(ByteBuf content) {
        throw new IllegalStateException("Replacing MultiByteHttpData is not supported");
    }

    @Override

View on GitHub (pinned to e1c734241f)

Solutions

Avoid copying MultiByteHttpData; reuse the same instance or create a new one with the same content
Wrap the copy call and fall back to re-reading the source file/part into a new MultiByteHttpData
Use duplicate()/retainedDuplicate() alternatives only if you handle their own unsupported exceptions

Example fix

// before
FileUpload copy = fileUpload.copy();
// after
FileUpload copy = new MultiByteHttpData(name, filename, contentType, charset);
copy.setContent(fileUpload.getByteBuf());

Defensive patterns

Strategy: fallback

Validate before calling

if (data instanceof MultiByteHttpData) { /* do not call copy() */ }

Type guard

boolean isCopyable(InterfaceHttpData d) { return !(d instanceof MultiByteHttpData); }

Try / catch

try { return upload.copy(); } catch (IllegalStateException e) { return rebuildUpload(upload); }

Prevention

Check the concrete FileUpload type before cloning operations
Reuse instances instead of copying multipart parts
Read the class docs for unsupported interface methods

When it happens

Trigger: Calling FileUpload.copy() on a MultiByteHttpData instance, typically indirectly via framework code that clones HttpData objects while building or transforming a multipart request.

Common situations: Middleware or interceptors that duplicate file upload parts before sending; code ported from classic Netty HttpPostRequestEncoder usage that assumes copy() works on all FileUpload implementations.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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