allthingssecurity opened a new pull request, #27530:
URL: https://github.com/apache/camel/pull/27530

   # Description
   
   [CAMEL-25355](https://issues.apache.org/jira/browse/CAMEL-25355)
   
   Follow-up to a point @davsclaus raised in the review of #27346 
(CAMEL-25305): `text/plain; charset=` (empty value) made 
`NettyHttpHelper.getCharsetFromContentType` return `""`, the consumer set an 
empty `CamelCharsetName`, and later conversions failed in 
`Charset.forName("")`. We fixed it there as in `UndertowHelper`. The shared 
helpers have the same problem:
   
   - `IOHelper.getCharsetNameFromContentType` (camel-util) returns `""` for 
`charset=`, `charset=""` or `charset=; format=flowed`, instead of its default 
`UTF-8`;
   - `HttpUtil.getCharsetFromContentType` (camel-support, behind 
`HttpHelper.setCharsetFromContentType`) returns `""` instead of `null`;
   - `DefaultHttpBinding.readHeaders` (camel-http-common) copies 
`HttpServletRequest.getCharacterEncoding()`, which is also `""` for these 
values on Tomcat and Undertow.
   
   The callers store this as `CamelCharsetName` (`CamelServlet`, Jetty's 
`CamelContinuationServlet`, `HttpProducer`, ...), so a servlet or Jetty route 
that reads the body as a `String` answers 500, and the HTTP producer cannot 
read the response body as a `String` (`IllegalCharsetNameException` from 
`ExchangeHelper.getCharset`).
   
   This change treats an empty charset value as no charset, as `UndertowHelper` 
and `NettyHttpHelper` do: `IOHelper.getCharsetNameFromContentType` returns its 
default `UTF-8`, `HttpUtil.getCharsetFromContentType` returns `null`, and 
`DefaultHttpBinding` ignores an empty `getCharacterEncoding()` (a form body is 
then decoded as UTF-8, as without a charset). Content types with a charset, or 
without one, are handled as before; only messages that failed before change, so 
there is no upgrade guide entry. One corner case: `VertxBufferConverter` and 
`VertxHttpHelper.getCharsetFromExchange` fell back to the `CamelCharsetName` 
exchange property when the Content-Type had an empty charset; they now use 
UTF-8, as they already did for a Content-Type without a charset. The vertx-http 
producer (`DefaultVertxHttpBinding`), which stored the empty name and failed 
like the HTTP producer, now uses UTF-8, and `VertxPlatformHttpSupport` still 
writes such a String response as UTF-8.
   
   Not changed (outside Camel): the embedded Undertow fails itself on a 
`charset=` at the very end of the header, and Jetty 12 rejects `charset=""` in 
`getContentType()`, so the servlet and Jetty tests use the forms those 
containers accept.
   
   Tests:
   - `IOHelperTest.testCharsetEmpty` (camel-util) and new 
`HttpUtilTest.testGetCharsetFromContentTypeEmptyCharset` (camel-support);
   - new `ServletEmptyCharsetParameterTest` (3 empty forms and a form POST), 
`JettyEmptyCharsetParameterTest` (`charset=`) and 
`HttpProducerEmptyCharsetParameterTest` (3 empty forms in the response).
   
   All new tests fail without the change (two runs) and pass with it. Module 
suites with the change: camel-util (295 tests), camel-support (126), 
camel-http-base (50), camel-http-common (36), camel-servlet (106, 2 skipped), 
camel-http (262, 9 skipped), camel-jetty-common (9), camel-jetty (399, 23 
skipped; `JettyXsltHttpTemplateTest` fails on my machine with and without the 
change, `0.0.0.0` binding) and camel-core `IOHelperTest` pass.
   
   This touches `DefaultHttpBinding` like the CAMEL-25133 and CAMEL-25316 
changes; the three merge without conflict, and with all three applied together 
the camel-util (295), camel-support (126), camel-http-base (50), 
camel-http-common (39), camel-servlet (109, 2 skipped), camel-jetty-common (9), 
camel-http (262, 9 skipped), camel-jetty (399, 23 skipped; only 
`JettyXsltHttpTemplateTest` fails, as without the changes), camel-vertx-http 
(97, 1 skipped) and camel-platform-http-vertx (150, 1 skipped) tests pass.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] 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).
   
   # 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 the affected modules, 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 commits carry 
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]

Reply via email to