allthingssecurity opened a new pull request, #27924: URL: https://github.com/apache/camel/pull/27924
# Description [CAMEL-25685](https://issues.apache.org/jira/browse/CAMEL-25685) `AttachmentHttpBinding.populateRequestParameters` maps the query parameters through `request.getParameterNames()`. Jetty 12 reads the body parameters and the query parameters together there, and throws for the whole request when it cannot read the body parameters. The `catch` around the loop only logs at DEBUG, so the exchange is routed without any query parameter and the client gets 200. Two requests that I measured take this path: - a form-urlencoded POST with a body over Jetty's `maxFormContentSize` (200000 bytes by default), default options. The form fields are still mapped (Camel parses them from the body in `readFormUrlEncodedBody`); only the query parameters are lost. Example: `POST /upload?customerId=42` with a 250 KB form gives `header("customerId") == null`; - any multipart request on an endpoint with `enableMultipartFilter=false`, whatever its size. The catch was written for this case; the query parameters were dropped together with the multipart body parameters. When `getParameterNames()` itself fails (for any reason, not only these two), the query string is now decoded with Jetty's `UrlEncoded.decodeQuery` (UTF-8, Jetty's default query encoding) and its parameters are mapped like on the normal path: values sanitized with `HttpHelper.sanitizeLog`, the header filter strategy applied, a repeated name as a list. A query that cannot be decoded (`%E9`) is still skipped with the DEBUG log, unchanged. Requests that Jetty reads without error take the same path as before. Other consumers with the same request (`?q=1&q2=x`, default options): camel-servlet (in the module's Undertow container) maps everything for a 250 KB form and answers 413 at 3 MB; camel-undertow maps everything for large bodies (413 at 3 MB, 500 above 1000 form keys); camel-platform-http-vertx answers 400. camel-jetty was the only one that routed the exchange without the data (plain jetty endpoints; REST DSL endpoints see below). No option or default changes. The only visible difference is that these requests now get their query parameter headers, as every other request to the same endpoint does. For multipart requests with `enableMultipartFilter=false` these headers are missing on every release branch that has the catch (4.18.x, 4.22.x, 4.23.x; read, not run). I did not add an upgrade guide entry for that; I can add a short camel-jetty note if you prefer. Overlap: #27852 (CAMEL-25634) changes the attachment branch inside the same `try`. The two changes touch different lines and merge without conflict. Tests: - New `HttpBindingQueryParametersUnreadableBodyTest`, 4 tests. On main 3 fail with `expected: <42> but was: <null>`: query parameters of a 250 KB form (including a repeated name and `+` as space, and the form fields still mapped), a `CamelHttpResponseCode` query parameter on a large form that the header filter strategy must still drop, and a multipart request with `enableMultipartFilter=false`. The fourth (`?id=%E9` with a large form, not mapped) passes on main and pins the unchanged path for a query that cannot be decoded. - camel-jetty with the change (camel-http-base and camel-http-common in the same reactor): 407 tests, 23 skipped, 1 failure and 1 error that also occur without the change on my machine: `JettyXsltHttpTemplateTest` (fetches the stylesheet from `0.0.0.0` and gets `Unexpected end of file from server`) and `JettyEmptyCharsetParameterTest` (500; my local camel-support snapshot is older than main). Not changed: - an invalid query escape still drops all parameters of the request (malformed client input, a separate case); - Jetty's form limits are not exposed as endpoint options; - REST DSL endpoints on jetty use `JettyRestHttpBinding`, which goes through `DefaultHttpBinding.populateRequestParameters` without this catch: there a 250 KB form or a multipart request with a query answers 500 (measured). That fails loudly rather than losing data, so it is left as it is here. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [ ] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). (The ticket is drafted and not filed yet; CAMEL-25685 is a placeholder until it is.) # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-jetty, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
