mcarbonneaux commented on code in PR #2411:
URL: https://github.com/apache/cxf/pull/2411#discussion_r2105916150
##########
rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java:
##########
@@ -425,6 +425,9 @@ protected void setupConnection(Message message, Address
address, HTTPClientPolic
}
}
String verc =
(String)message.getContextualProperty(FORCE_HTTP_VERSION);
+ if (verc == null && "http".equals(uri.getScheme())) {
Review Comment:
a) if the HttpClient default is bad, cxf are not oblige to follow if it's
deserve the real usage... when http/2 while be correctly implemented every
where on http... ok you can go back to the default...
b) the defaults are not right only for me... it's generally problematic
because how http/2 as been conceived (not only on java, the majority of the
implementation are buggy and only used in m2m use case)... with https in mind
(quasi all browser don't implement h2c, http/2 over cleartext TCP)...
and with FORCE_HTTP_VERSION (even if it's enforced in http1.1 by default)
you can enforce back to http2 is it's work with the backend you use...
chrome, firefox, edge and safari don't implement h2c...
the google service not implement h2c...
in this case most of the http2 server implementation are badly tested and
implemented...
and only used in machine 2 machine use case...
for this reason majority of the http2 usage are only used on https...
and for this reason is more safe to default to http1.1 on http...
in my case my soap usage on http are only on private network... on internet
i use only https and cxf code used in this case as not problem with http2....
https://stackoverflow.com/questions/34076231/why-do-browser-implementations-of-http-2-require-tls
plus the rfc of http2 as no option for server not supporting http2 (h2c)
over http to response to the client to fallback to http1.1...
--
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: dev-unsubscr...@cxf.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
