Andrea Cosentino created CAMEL-24496:
----------------------------------------
Summary: 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
{{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)
