[
https://issues.apache.org/jira/browse/CAMEL-24496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-24496:
-------------------------------------
Fix Version/s: 4.23.0
> camel-platform-http-starter - align SpringBootPlatformHttpBinding multipart
> and path handling with the other HTTP bindings
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24496
> URL: https://issues.apache.org/jira/browse/CAMEL-24496
> Project: Camel
> Issue Type: Improvement
> Components: camel-platform-http, camel-spring-boot-starters
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> {{SpringBootPlatformHttpBinding.populateAttachments()}} and
> {{populateRequestParameters()}} diverge from the equivalent bindings in the
> other HTTP server components. Four separate items, all in the same class:
> *1. Filename normalisation (continues CAMEL-24293)*
> {code:java}
> message.setHeader(Exchange.FILE_NAME, multipartFile.getOriginalFilename());
> {code}
> CAMEL-24293 applied {{FileUtil.stripPath(...)}} to externally-derived names
> before setting {{CamelFileName}} in camel-platform-http-vertx, camel-zipfile
> and camel-tarfile. The Spring Boot binding lives in this repository and was
> not covered by that change, so it still sets the header from the raw
> submitted name. The same normalisation should be applied here. The binding
> also sets {{Exchange.FILE_PATH}} to the absolute server temp path, which is
> more than callers need.
> *2. fileNameExtWhitelist checked against the wrong value (same defect as
> CAMEL-24427)*
> {code:java}
> multipartHttpServletRequest.getFileMap().forEach((name, multipartFile) -> {
> ...
> if (getFileNameExtWhitelist() != null) {
> String ext = FileUtil.onlyExt(name);
> if (ext != null) {
> ext = ext.toLowerCase(Locale.US);
> if (!getFileNameExtWhitelist().equals("*") &&
> !getFileNameExtWhitelist().contains(ext)) {
> accepted = false;
> }
> }
> }
> {code}
> CAMEL-24427 covers this for camel-servlet and camel-jetty; this is the third
> binding with the same shape. Here {{name}} is the multipart *field* key from
> {{getFileMap()}}, not {{multipartFile.getOriginalFilename()}} - and line 135
> propagates the original filename downstream regardless. Three issues: the
> wrong value is checked; a key with no extension leaves {{accepted}} true; and
> {{contains(ext)}} is a substring test, so a whitelist of {{pdf}} also matches
> {{pd}}. camel-platform-http-vertx remains the correct reference
> implementation.
> *3. Upload written before the check, and not removed when rejected*
> {{multipartFile.transferTo(uploadedTmpFile)}} runs before the whitelist
> decision, and the rejection branch only logs, leaving the file in the servlet
> temp directory for the lifetime of the process.
> *4. Path variables derived from the raw URI*
> {{getRawPath()}} returns {{request.getRequestURI()}} - undecoded and with
> matrix parameters intact - and {{HttpHelper.evalPlaceholders}} is evaluated
> against it. Spring has already parsed and cached a decoded {{RequestPath}};
> using it would make the header values agree with the path Spring matched, and
> with the Vert.x engine's decoded behaviour.
> *Proposal*
> - Apply {{FileUtil.stripPath(...)}} to the name before setting
> {{CamelFileName}}; stop setting {{Exchange.FILE_PATH}}.
> - Evaluate the whitelist against {{getOriginalFilename()}}, treat a missing
> extension as not accepted when a whitelist is configured, and compare by
> splitting on {{','}} with trimmed case-insensitive equality.
> - Decide before {{transferTo()}}, or delete the temp file on the rejection
> branch and register it for cleanup when the unit of work completes.
> - Extract path variables from
> {{ServletRequestPathUtils.getParsedRequestPath}} instead of re-deriving from
> {{getRequestURI()}}.
> Tests per item, mirroring the camel-servlet/camel-jetty tests added under
> CAMEL-24427.
> ----
> _This issue was drafted by Claude Code on behalf of Andrea Cosentino._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
