Vaadin Upload on iOS

Are there any known issues (that I couldn’t find) related to Vaadin’s Upload component on iOS/Safari?
We have the weird problem, that for most files the uploading connection and even the WebSocket (which shouldn’t be directly involved in the upload AFAIK) are closed.
See below for the exception logged on the server. iOS Safari seems to receive HTTP status 500 and also logs that the WebSocket connection was closed unexpectedly. After a bit the browser/the Vaadin application reconnects and is responsive again.
Any idea on what might close those connections? Both sides seem kind of surprised based on the logs. There’s no (reverse) proxy in between.
The Vaadin application is a Spring Boot fat jar with embedded Tomcat. Vaadin is 23.3.25. Stream closed
    at org.apache.catalina.connector.InputBuffer.throwIfClosed(
    at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(
    at org.apache.commons.fileupload.MultipartStream$
    at java.base/
    at org.apache.commons.fileupload.util.Streams.copy(
    at org.apache.commons.fileupload.util.Streams.copy(
    at org.apache.commons.fileupload.MultipartStream.readBodyData(
    at org.apache.commons.fileupload.MultipartStream.discardBodyData(
    at org.apache.commons.fileupload.MultipartStream.skipPreamble(

Turns out it wasn’t related to iOS, but different file sizes (and people on different systems using different file sizes to test). Sizes < 1MB and > 10MB worked. Sizes between 1MB and 10MB lead to the above error. Those numbers are related to spring.servlet.multipart.max-file-size (default 1MB) and spring.servlet.multipart.max-request-size (default 10MB). But it’s not necessary to increase both to the max file size you want to support. It’s only necessary to ensure that max-file-size isn’t smaller than max-request-size. So e.g. setting both to 1MB will still allow to upload files > 1MB.
So, from what I can tell, Vaadin is supposed to handle the upload itself. But RequestUtil#isFrameworkInternalRequest(…) (used within security) tries to read parameters from the request which tries to parse the request. That parsing considers max-file-size and max-request-size, but those exceptions are swallowed. But exceeding max-file-size will lead to the underlying buffer to be closed (which later causes the stacktrace above), while exceeding max-request-size doesn’t really matter. So there’s some (hard to diagnose) weirdness going on.