oscerd opened a new pull request, #26189: URL: https://github.com/apache/camel/pull/26189
## Issue [CAMEL-24427](https://issues.apache.org/jira/browse/CAMEL-24427) ## Problem The three HTTP server components that accept multipart uploads disagreed about the upload filename check. **camel-servlet** — `AttachmentHttpBinding.populateAttachments()` checked the whitelist against `Part.getName()`: ```java String fileName = part.getName(); if (getFileNameExtWhitelist() != null) { String ext = FileUtil.onlyExt(fileName); ``` `Part.getName()` is the multipart *field* name, not the submitted file name. A field named `file` has no extension, so `FileUtil.onlyExt` returned `null`, `accepted` stayed `true`, and the whitelist never rejected anything. **camel-jetty** (`jetty12/AttachmentHttpBinding`) had no whitelist check at all, although `fileNameExtWhitelist` can be set on its `HttpBinding`. **camel-platform-http-vertx** checks `upload.fileName()` against the whitelist while keying the attachment on `upload.name()` — the correct reference implementation, unchanged here. ### Second defect in the camel-jetty binding ```java am.addAttachmentObject(part.getName(), attachment); String name = part.getSubmittedFileName(); Object value = am.getAttachment(name); ``` The attachment is stored under the field name and then looked up by the submitted file name. The lookup only succeeded when the two happened to be equal, and when it did, the header was named by the client-supplied file name. ## Investigation The block was added in `CAMEL-14105` (2019) when `MultiPartInputStreamParser` was replaced by `request.getParts()`, to keep exposing multipart parts as headers. `MultiPartFormTest` locks the intent in — it asserts `in.getHeader("log4j2.properties")` is the attachment's `DataHandler` — and passes today only because `addBinaryBody(file.getName(), file)` makes the field name and the file name identical. `populateRequestParameters` runs **before** `populateAttachments` (`DefaultHttpBinding` lines 198 / 208) and already maps plain form fields to headers, and `HttpHelper.appendHeader` *appends*. Exposing every part here would therefore have turned `MultiPartFormTest`'s `comment` header into a `List`. The header exposure is consequently gated on the part carrying a file name. ## Fix - `camel-servlet` — check `part.getSubmittedFileName()`. - `camel-jetty` — apply the same check, extracted into `isFileNameAccepted`. - `camel-jetty` — look the attachment up under the key it was stored with (`part.getName()`) and name the header after it, only for parts that carry a file name. Attachment keying is unchanged in both components: still the multipart field name. ## Tests - `MultipartUploadFileNameExtWhitelistTest` (camel-servlet) — the existing harness posts `name="file"; filename="test.txt"`, which is exactly the field-name vs file-name split. Asserts `fileNameExtWhitelist=txt` accepts and `fileNameExtWhitelist=pdf` rejects. - `MultiPartFormFileNameExtWhitelistTest` (camel-jetty) — uploads with field name `upload` and file name `log4j2.properties` so the two differ. Asserts the whitelist accepts/rejects, that the header exposing the attachment is named by the field name, and that the file name does **not** become a header name. Both verified failing before the change and passing after. Full module suites: camel-servlet 98/98, camel-jetty 393/393 (including the existing `MultiPartForm*` tests). Full reactor build clean. ## Documentation Behaviour change documented in `camel-4x-upgrade-guide-4_23.adoc` — a `camel-servlet` route that sets `fileNameExtWhitelist` starts rejecting uploads it previously let through, and a route reading the jetty attachment header under the uploaded file name must read it under the field name. ## Out of scope `fileNameExtWhitelist` is not exposed as a `camel-jetty` component or endpoint option at all; it can only be set programmatically on the binding. Adding the option is a separate change. --- _Claude Code on behalf of oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
