-
Notifications
You must be signed in to change notification settings - Fork 1.4k
try to fix incompatibility with http/2 with many http server... #2411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| } | ||
| } | ||
| String verc = (String)message.getContextualProperty(FORCE_HTTP_VERSION); | ||
| if (verc == null && "http".equals(uri.getScheme())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcarbonneaux the Apache CXF client conduit uses JDK HttpClient under the hood and relies on its behavior with respect to preferred protocol selection - which is HTTP/2 by default (https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/HttpClient.html#newHttpClient())
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But in real life http/2 on http is not very safe to use by default because at the origin spdy has been developed for https only, and when it's pass to the rfc process some participant want http but major implémenter implement only https...
In all my program I enforce by default to http/1.1 for http usage...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could direct your question towards OpenJDK community (since HttpClient is a part of the standard library). If server supports H2C, this is a choice of the consumer to use it or not, hence we have a property (FORCE_HTTP_VERSION) here. To your point, I think it does not disambiguate between H2C and H2, this is something we could extend FORCE_HTTP_VERSION with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is not juste openjdk (many server that are not emplementing http2 are not in Java) problem is http/2 problem... Multiple issue are open on openjdk h2 client on http... Fix exist (on recent version) ... It's very complex to understand that the problem come from httpclient from the jdk....
At minimum more documenting in cfx documentation about FORCE_HTTP_VERSION because each time I need to explain to my developer why there code are not working with http....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I will update documentation shortly to explain the HTTP protocol selection preferences, thank you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but with using of http 1.1 by default on http backend you have no chance to have problem... is why i've proposed to enforce http 1.1 on http...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcarbonneaux as I explained: a) we follow the HttpClient defaults b) if the defaults are not right for you - please use the property (FORCE_HTTP_VERSION )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 with https in mind (google with spdy are only on tls), and is not only on java, the majority of the implementation are buggy and only used in m2m use case, because 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 no problem with HttpClient http2 default....
https://stackoverflow.com/questions/34076231/why-do-browser-implementations-of-http-2-require-tls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I also mentioned, if you disagree with HttpClient - please bring it to OpenJDK community or use another HTTP client conduit (Apache HttpClient 5 fe).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
httpclient leave you the posibility to choose... and cxf conduit can choose... cxf httpclient conduit are not oblige to follow the default of httpclient... if in majority of the time in cxf use case with http (more than 90% i think! in fact only java http backend using openjdk server http/2 work... and i think only with recent version of the openjdk...) is not working fine... because h2c are not realy implemented in fact on backend...
using http/2 by default is ok with tls/https.... but with http (h2c)... is not working fine at all... and i think while never work because majority of the implementer don't whant to implement...or badly implement it...
try to make a fix with http server only.
https://issues.apache.org/jira/browse/CXF-8896