allthingssecurity commented on code in PR #27245:
URL: https://github.com/apache/camel/pull/27245#discussion_r4163579305
##########
components/camel-undertow/src/main/java/org/apache/camel/component/undertow/UndertowHelper.java:
##########
@@ -174,4 +178,26 @@ public static URI makeHttpURI(URI httpURI) {
}
}
+ /**
+ * Encodes a String body to send over HTTP in the charset that the
Content-Type of the message declares, so that the
+ * bytes match the header.
+ *
+ * @param body the String body
+ * @param contentType the Content-Type of the request or response being
sent, may be <tt>null</tt>
+ * @return the encoded body, or <tt>null</tt> when the
Content-Type declares no charset or one that is
+ * not supported, in which case the body is converted
as before (UTF-8 by default)
+ */
+ public static ByteBuffer toByteBuffer(String body, String contentType) {
+ String name = contentType != null ?
Headers.extractQuotedValueFromHeader(contentType, "charset") : null;
Review Comment:
Thanks. Agreed: `Headers.extractQuotedValueFromHeader` matches `charset`
case-sensitively here and in the consumer's request-side parsing. Handling the
parameter name case-insensitively on both sides (RFC 7231) would be a sensible
follow-up, with tests for both directions. I kept this PR consistent with how
the module parses `charset` today, so `Charset=...` behaves the same as before.
_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]
