I followed the simple instructions in this Wildfly 10.1 news that enables HTTP/2 and TLS protocol on port 8443 and everything went perfectly.
But I would like to enable HTTP/2 protocol also in pages HTTP, getting this protocol in both HTTPS as in the HTTP.
It is possible?
And how I can make this change directly in the standalone-full.xml configuration file?
Thank you.
HTTP2 works only with SSL/TLS
Browsers do not support HTTP2 without encryption
HTTP/2 is is enabled by default on both the HTTP and HTTPS ports, however most browsers (with the exception of internet explorer) do not support HTTP/2 without encryption.
Related
Here is the situation:
Our client wants to back support some old ios mac systems, which the network lib it used does not support ALPN. Our Server is set up only to accept gRPC requests, so there is no need for the server to accept HTTP1.1 requests.
So how do I disable Nginx to accept HTTP1.1 request and only enable HTTP2 support and skip the ALPN?
I tried to make Nginx defaults to support http2 but it still involves the ALPN process.
it seems nginx is do http2 based on ALPN so there is no walkaround for that.
Our customer request http2 only service because other product they use are using gRPC with envoy proxy. Envoy seems to have the ability to provide http2 only service without alpn, but it is subject to find out why ( as the document does not specify it clearly)
I have various nginx server and recently I note that by default response these servers responses using the HTTP/2 version of protocol.
I don't have configured the http2 parameter in nginx.conf.
Is this the right behavior?
No, that is not the default.
If you observe HTTP2 despite not configuring it in NGINX, you likely have a CDN in front of it, e.g. Cloudflare.
After reading both HTTP/2 RFC (#7540) and TLS-ALPN RFC (#7301), I'm still unable
to figure out the expected behavior when ALPN is lacking in one end.
Assuming I have a client that uses HTTP/2 "h2" (over TLS) that talks to a server that support HTTP/2 but does not send the ALPN extension in the "server hello".
What is the expected behavior from the client?
Most clients I've seen so far consider that HTTP/2 is not supported by the server and downgrade the connection to http/1.1, but few ignore (go-gRPC) continue with HTTP/2.
This scenario can be more practical if using AWS classic LB that does SSL termination between a client ("h2") to the server ("h2c"). In this example, the client sends the ALPN extension with value of "h2", the LB performs SSL handshake without ALPN (as expected from his part), and eventually the JAVA gRPC fails due to HTTP/1.1 downgrade.
To answer the question, without alpn, but using npn, still can support grpc.
Two clarification,
http2 negotiation for grpc can happen either thru alpn or npn.
If alpn is supported in client, it sends alpn extension as well as npn extension in Client Hello.
If alpn is supported in server, server only responds with alpn with h2. If alpn not supported and npn is configuration in 'server LB config' it will send npn and h2.
What i noticed in haproxy and nginx if you dont configure alpn, it does not default to npn unless configured.
grpc client insists on h2. If neither alpn, nor npn with h2 happed, client will disconnect as it assumes h2 is not suppored, and h2 is mandatory for grpc
It depends entirely on the client and server. Many still support the older NPN TLS extension for SPDY and HTTP/2 Support, though officially the spec says to use ALPN only.
On the browser side, for example, Chrome, Firefox and Opera now only support HTTP/2 over ALPN though they all used to support it over NPN. At the time of writing Safari, IE and Edge still allow either NPN or ALPN to be used.
On the server side some (e.g. Nginx) Support both, while some (e.g. Apache) only Support ALPN.
I would also question the terminology of “downgrade”. The ALPN extension is a request to use h2 and happens as part of the TLS negotiation before a single HTTP message has been sent. So it’s not really a downgrade anymore than an unsuccessful upgrade request.
I want to set up my web page to make HTTP2 requests to a Jetty API server. I read that browsers will only use the "h2" protocol, that is, HTTP2 with TLS. However, my setup has a kubernetes ingress performing SSL termination, and proxying a cleartext request back to the Jetty server. The dilemma is that I don't think I want to negotiate an "h2" connection using Jetty, because that would require an SSL context on that server.
My question is, will this setup allow a browser to perform HTTP2 requests? If so, what do I need to enable on the Jetty server in order to properly serve HTTP2 requests?
You can configure Jetty to serve clear-text HTTP/2 (also known as h2c), so that your setup will be:
browser -- h2 --> kubernetes tls termination -- h2c --> Jetty
In order to setup Jetty with clear-text HTTP/2, you just need to enable the http2c module if you are using Jetty as a standalone server, see http://www.eclipse.org/jetty/documentation/current/http2-enabling.html.
Alternatively, if you're using Jetty embedded you can look at this example.
To implement HTTP/2 support on nginx/1.11.1, I'm going to redirect all HTTP Request to HTTPS.
In this case, how will Bot and Browsers, that don't support HTTP/2 protocol, behave and render the page?
Is there a way for me to simulate HTTP/1.1 browser behavior on Chrome Developer Tools?
You are mixing two concepts here that are somehow related, but they are largely different: HTTP to HTTPs redirect, and HTTP 1.1 vs HTTP/2 negotiation.
Redirecting HTTP to HTTPS requests is fine. Virtually every client (browser, bot, etc) available these days is capable of understanding HTTPS requests.
As for HTTP 1.1 vs HTTP/2, Nginx will fallback to HTTP 1.1 if the HTTP/2 connection fails because the client doesn't support it.
Last but not least, this question has very little to do with StackOverflow. It is more appropriate in ServerFault or SuperUser.
Potentially interesting
TCP retransmission will increase. This could lead on poorly configured devices for connection abort.