oscerd commented on issue #9055:
URL: https://github.com/apache/camel-quarkus/issues/9055#issuecomment-5422316835
Looked into this. The dead guard is real, but the suggested fix — applying
the multipart configuration only when the deployer configured it — cannot be
done without a breaking change, because always-on multipart is intentional and
covered by a test.
`CamelServletTest.multipartDefaultConfig` posts a multipart request to
`/folder-1/multipart/default`, which is served by the **default** servlet
(`quarkus.camel.servlet.url-patterns=/folder-1/*`). That servlet has no
`multipart.*` configuration at all, and the route
```java
from("servlet://multipart/default?attachmentMultipartBinding=true")
```
relies on the parts being parsed. Making `multipart()` an `Optional` config
group would leave that servlet without a `MultipartConfigElement` and break the
test — and, more importantly, any application that consumes multipart requests
today without configuring anything.
The unlimited `-1` defaults are also documented as such on `max-file-size`
and `max-request-size`, so tightening them would be a separate behavioural
decision rather than a bug fix.
So I've scoped this to the part that is unambiguously wrong: the `if
(multipartConfig != null)` check can never be false under `@ConfigMapping`, and
it reads as though multipart were conditional when it is not. The PR removes it
and documents why multipart is applied unconditionally, leaving behaviour
unchanged.
If tightening the default sizes or making multipart opt-in is wanted, that
is worth a separate issue with a migration note.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
