allthingssecurity commented on code in PR #27346:
URL: https://github.com/apache/camel/pull/27346#discussion_r4181332139
##########
components/camel-netty-http/src/main/java/org/apache/camel/component/netty/http/NettyHttpHelper.java:
##########
@@ -56,6 +56,26 @@ public static void appendHeader(Map<String, Object> headers,
String key, Object
CollectionHelper.appendEntry(headers, key, value);
}
+ /**
+ * Gets the charset parameter of the content type. The parameter name is
case-insensitive (RFC 9110, section 5.6.6).
+ *
+ * @param contentType the content type, may be <tt>null</tt>
+ * @return the charset name, or <tt>null</tt> if the content
type has no charset parameter
+ */
+ public static String getCharsetFromContentType(String contentType) {
+ if (contentType == null) {
+ return null;
+ }
+ String[] parts = contentType.split(";");
+ for (int i = 1; i < parts.length; i++) {
+ String part = parts[i].trim();
+ if (part.regionMatches(true, 0, "charset=", 0, 8)) {
+ return IOHelper.normalizeCharset(part.substring(8));
Review Comment:
Done in c69826ad69b2: `getCharsetFromContentType` returns `null` for an
empty value (`charset=` and `charset=""`), as
`UndertowHelper` does. Added a unit check for both forms and a consumer
test: a request with `text/plain; charset=`
sets no `CamelCharsetName` and its body is read as before. Both checks fail
without the guard. For the record, the
deprecated `HttpUtil.getCharsetFromContentType` that the consumer used on
main also returned `""` here, so this was not
new in the PR, but it is fixed now. Module suite: 282 tests, 0 failures, 8
skipped.
_Claude Code on behalf of allthingssecurity_
##########
docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc:
##########
@@ -780,6 +780,16 @@ The `charset` parameter of a `Content-Type` was only
recognized in lower case. A
`String` body with such a `Content-Type` was written as UTF-8. The parameter
name is now matched case-insensitively
(RFC 9110), as in the other HTTP components, on the consumer (request and
response) and on the producer.
+=== camel-netty-http - String bodies in the charset of the Content-Type
+
+The Netty HTTP consumer (response) and producer (request) wrote a `String`
body in the charset of the exchange
+(`CamelCharsetName`, UTF-8 by default), even when the `Content-Type` declared
another charset (for example
+`text/plain; charset=ISO-8859-1` set by the route). A `String` body is now
written in the charset that the
+`Content-Type` declares. Bodies that are not a `String`, and messages whose
`Content-Type` declares no charset, are
+sent as before. Also, the `charset` parameter of a received `Content-Type` (a
request on the consumer) is now
+recognized whatever its case (`Charset=ISO-8859-1`). A peer that ignored the
declared charset and read such a message as UTF-8 must now use the
Review Comment:
Re-wrapped to the ~120 columns of the surrounding text in c69826ad69b2.
_Claude Code on behalf of allthingssecurity_
--
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]
