With the recent rollout of Chromium 124 to Chrome, a new "Priority" HTTP header has been introduced in the request header that supports the HTTP/2 and HTTP/3 protocols by default. More info about the new header can be found in the following link:
https://developer.chrome.com/release-notes/124#priority_http_request_header
However, the Spring Integration library hasn't seem to catch up with this change and is still expecting the Priority header in NUMBER format, whereas the actual header value is in such format as "u=5, i". More info on the format definition here:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority#name-the-priority-http-header-fi
This header validation is happening in IntegrationMessageHeaderAccessor in the spring-integration-core artifact:
Here is the extract of the method where the validation is taking place, with the Priority validation logic in bold:
@Override
protected void verifyType(String headerName, Object headerValue) {
if (headerName != null && headerValue != null) {
super.verifyType(headerName, headerValue);
if (IntegrationMessageHeaderAccessor.EXPIRATION_DATE.equals(headerName)) {
Assert.isTrue(headerValue instanceof Date || headerValue instanceof Long,
TYPE_VERIFY_MESSAGE_FUNCTION.apply(headerName, "' header value must be a Date or Long."));
}
else if (IntegrationMessageHeaderAccessor.SEQUENCE_NUMBER.equals(headerName)
|| IntegrationMessageHeaderAccessor.SEQUENCE_SIZE.equals(headerName)
|| IntegrationMessageHeaderAccessor.PRIORITY.equals(headerName)) {
Assert.isTrue( Number.class.isAssignableFrom(headerValue.getClass()),
TYPE_VERIFY_MESSAGE_FUNCTION.apply(headerName, "' header value must be a Number."));
}
else if (IntegrationMessageHeaderAccessor.ROUTING_SLIP.equals(headerName)) {
Assert.isTrue( Map.class.isAssignableFrom(headerValue.getClass()),
TYPE_VERIFY_MESSAGE_FUNCTION.apply(headerName, "' header value must be a Map."));
}
else if (IntegrationMessageHeaderAccessor.DUPLICATE_MESSAGE.equals(headerName)) {
Assert.isTrue( Boolean.class.isAssignableFrom(headerValue.getClass()),
TYPE_VERIFY_MESSAGE_FUNCTION.apply(headerName, "' header value must be an Boolean."));
}
}
}
Is anyone aware of any patch to the Spring Integration code base with regard to this change? Please advise.
Thanks!
As a workaround currently, we intercepted the request and filter out the header before it reaches the validation point and that resolves the issue. But it feels more appropriate that this should be fixed in the Spring library level since the browser change is already official.