Corrupt filename in Upload component when server's file encoding is not UTF-8

[mas4ivv]

Description of the bug

When using the Upload component with a filename that has non-ASCII characters, the server receives a corrupt filename if it's file encoding is not UTF-8.
The filename is part of the upload request and seems to be UTF-8 encoded:

The filename is then read via Apache Commons' ServletFileUpload, created by StreamReceiverHandler.getItemIterator(VaadinRequest). As there is no encoding set on creation, it falls back to the server's default.

Example running the example below from Windows command line:

Expected behavior

It seems to me that the client is always sending the filename UTF-8 encoded. If this is correct, the ServletFileUpload created in StreamReceiverHandler should be configured to use UTF-8 by calling setHeaderEncoding("UTF-8").

Minimal reproducible example

import java.io.ByteArrayOutputStream;

import com.vaadin.flow.component.orderedlayout.VerticalLayout;
import com.vaadin.flow.component.textfield.TextField;
import com.vaadin.flow.component.upload.Upload;
import com.vaadin.flow.router.Route;

@Route("upload")
public class UploadPage extends VerticalLayout {

    public UploadPage() {
        Upload upload = new Upload();
        TextField filename = new TextField();
        upload.setReceiver((name, type) -> {
            filename.setValue(name);
            return new ByteArrayOutputStream();
        });
        this.add(upload, filename);
    }
}

Versions

• Vaadin / Flow version: 23.4.1
• Java version: 11
• OS version:
• Browser version (if applicable):
• Application Server (if applicable):
• IDE (if applicable):

[tepi]

@mas4ivv I was unfortunately unable to reproduce this on macOS (uses UTF-8 by default, but even changing the server JVM encoding to soemthing else did not break the special characters). Are you by any chance on Windows?

[mas4ivv]

Yes, the example was run on Jetty on Windows. Our production server is running on Linux and has the same problem.

[tepi]

Alright, in that case it should be reproducable on mac as well since I think most Linux default to utf-8 anyway. I'll retry.

[tltv]

@mas4ivv Could you please clarify these questions to help us reproducing the issue and find good fix for it. Also if possible, attaching full example application would also answer some of these:

• which browser you use? or is it maybe same with all you try?
• which jetty version you use?
• is there any customization in the app for jetty configurations or request handlers/filters that could change request's character encoding (with ServletRequest.setCharacterEncoding(String))?

Example code generates a request with content type of multipart/form-data with one part in the request body. This looks correct in the screenshot. With parts in the body, StreamReceiverHandler.getItemIterator(VaadinRequest) method should not be called at all. There's a hasParts method that decides how to process the body, and both are using different APIs. If possible, could you confirm by putting a brake point in StreamReceiverHandler.getItemIterator(VaadinRequest) and confirm if it's actually called? I can't see how it would with such a request. But if it does, then that seems a bug.

Updating Flow to always call ServletFileUpload.setHeaderEncoding("UTF-8") would probably not help with parts in the body. But forcing it to UTF-8 in other place could potentially fix the issue.

[mas4ivv]

Hi,
I can reproduce the error with both Firefox and Chrome, using Jetty 10.0.24. Here is the complete demo app:
upload_sample.zip

I'm adding -Dfile.encoding=ISO8859-15 on startup, if I specify UTF-8 everything works fine.

I added breakpoints at hasParts and getItemIterator - the first is throwing an exception:

java.lang.IllegalStateException: No multipart config for servlet
No multipart config for servlet
java.lang.IllegalStateException: No multipart config for servlet
	at org.eclipse.jetty.server.Request.getParts(Request.java:2337)
	at org.eclipse.jetty.server.Request.getParts(Request.java:2328)
	at javax.servlet.http.HttpServletRequestWrapper.getParts(HttpServletRequestWrapper.java:317)
	at com.vaadin.flow.server.communication.StreamReceiverHandler.getParts(StreamReceiverHandler.java:637)
	at com.vaadin.flow.server.communication.StreamReceiverHandler.hasParts(StreamReceiverHandler.java:225)
	at com.vaadin.flow.server.communication.StreamReceiverHandler.doHandleMultipartFileUpload(StreamReceiverHandler.java:198)
	at com.vaadin.flow.server.communication.StreamReceiverHandler.handleRequest(StreamReceiverHandler.java:159)
	at com.vaadin.flow.server.communication.StreamRequestHandler.handleRequest(StreamRequestHandler.java:116)
	at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1563)
	at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:369)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)

so it seems that getItemIterator gets called as a fallback (this is the same for all encodings).

I also tried setting ServletFileUpload.setHeaderEncoding("UTF-8") while debugging - this solves the problem for me.

[tltv]

Thank you. Key for reproducing was to run without multipart config so Flow will fallback to non-multipart upload.

Setting header encoding always to UTF-8 in case when request's character encoding is not explicitly set seems now correct fix. This because ServletFileUpload uses now primarily request's character encoding or if it's null then system's default. And in this test app request's encoding seems to be null.

[vaadin-bot]

This ticket/PR has been released with Vaadin 23.5.12.

[vaadin-bot]

This ticket/PR has been released with Vaadin 24.4.18.