How does a website behave on a client that does not support the HTTP/2 protocol?Is there a backward compatibility of the server that the server falls back on HTTP/1?
Standard webservers will handle HTTP 1.x requests just fine and reply with HTTP 1.x responses. There are just too many browsers out there that don't speak HTTP/2 yet to completely drop HTTP 1.x support from a server.
Related
If the browser supports http/2, why does grpc-web require envoy proxy?
Is it just required for older browsers that do not support http/2?
Answered in https://github.com/grpc/grpc-web/issues/347. For gRPC-Web to work, we need a lot of the underlying transport to be exposed to us but that's not the case currently cross browsers. We cannot leverage the full http2 protocol given the current set of browser APIs.
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.
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.
Question
If 2 HTTP requests are made to the same server at the same time from fresh, e.g. GET /image1.png HTTP/1.1 & GET /image2.png HTTP/1.1 with no previous connection to the server. Then should 1 TCP connection be made or 2?
Info
Persistent connections supported by default in HTTP 1.1. HTTP 1.0 uses the Connection: Keep-Alive.
It seems pretty clear from reading the RFC that if the above requests are made one after each other then the second request should reuse the connection.
HTTP Pipelining is sending multiple requests down the same connection without first waiting for a response. I am not sure where this fit into the answer tho.
If 2 HTTP requests are made to the same server at the same time from fresh, e.g. GET /image1.png
If the requests are made by the browser simultaneously (and there is no HTTP proxy server), then there will be two connections made to the server (unless http pipelining is enabled). Per the wikipedia article on pipelining,
Out of all the major browsers, only Opera based on Presto layout engine had a fully working implementation that was enabled by default. In all other browsers HTTP pipelining is disabled or not implemented.
Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.
Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino) support pipelining, however it is disabled by default. Pipelining is disabled by default to avoid issues with misbehaving servers. When pipelining is enabled, Mozilla browsers use some heuristics, especially to turn pipelining off for older IIS servers.
Konqueror 2.0 supports pipelining, but it's disabled by default.
Google Chrome supports pipelining for HTTP in the stable release as a non-default option (starting with version 18). There is no support for pipelining HTTPS yet.[11] As of version 26, the flag to enable HTTP pipelining in Chrome has been disabled.
So, probably two connections.
I enabled http pipelining support in google chrome and observerd some problems in how data is received even when using big sites like amazon.com. What is the current support for pipelining from major servers ? I wonder if issues can be caused also because of our transparent proxy (microsoft TMG) although http://technet.microsoft.com/en-us/library/cc302548.aspx mentions that
"ISA Server does not implement pipelining. Client request pipelining is supported, allowing a client to make multiple requests without waiting for each response. However, pipelining when sending requests to the Web server is not supported." I think this should not cause data to be received wrongfully from the pipeline aware web server.