davsclaus commented on code in PR #27346:
URL: https://github.com/apache/camel/pull/27346#discussion_r4181088559
##########
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:
`text/plain; charset=` (empty value) returns `""` here. The consumer then
sets an empty `CamelCharsetName` on the exchange, and later conversions fail in
`Charset.forName("")`. `UndertowHelper.getCharsetFromContentType` guards this
case; please do the same (`ObjectHelper` is already imported):
```suggestion
String name = IOHelper.normalizeCharset(part.substring(8));
return ObjectHelper.isEmpty(name) ? null : name;
```
##########
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:
Nit: this line is much longer than the ~120-column wrap of the surrounding
text. Please re-wrap it.
--
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]
