Thank you, Chuck and Mark, for the detailed feedback. Really helpful. Regarding " protocol=org.apache.coyote.http2.Http2Protocol" , it was more of a question to support pure HTTP/2 like protocol attribute. Sorry for confusion.
Thanks, Amit -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, February 12, 2025 2:12 AM To: users@tomcat.apache.org Subject: Re: HTTP/2 support in Tomcat CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. On 12/02/2025 02:50, Chuck Caldarale wrote: > >> On 2025 Feb 11, at 19:21, Amit Pande <amit.pa...@veritas.com.invalid> wrote: >> >> Am planning to update the Tomcat configuration to support HTTP/2. >> >> Wanted to understand the difference between >> >> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/> >> nested within the HTTP/1.1 connector >> >> Vs >> >> Supporting protocol=org.apache.coyote.http2.Http2Protocol in the connector >> configuration. > > > I don’t see anywhere in the documentation for supported Tomcat levels where > the “protocol=…Http2Protocol” setting is allowed. Correct. It isn't. > Where did you come up with that? > > >> As I understand using the upgrade protocol mechanism allows to fallback on >> HTTP 1.1 in case the client and server don't agree on HTTP2. Is this right >> understanding? > > > Yes - hence the <UpgradeProtocol> element within the <Connector> element > rather than an additional protocol attribute. It is a little more complicated than that. Because either HTTP/1.1 or HTTP/2 can be used via the same host+port combination (Connector in Tomcat configuration) we needed a way to link multiple protocols to the Connector which is why the <UpgradeProtocol> element is used. It does more than just support HTTP upgrade though. The available mechanisms to select the protocol depend on whether TLS is being used or not. The possible ways to start an HTTP/2 connection are: For non-TLS connections: - HTTP Upgrade from HTTP/1.1 (deprecated) - HTTP/2 connection preface For TLS connections - ALPN HTTP upgrade requires an existing HTTP/1.1 connection. The client can request an upgrade. If the server doesn't agree, they continue using HTTP/1.1. If the server receives an HTTP/2 connection preface and doesn't understand it, the likely result is a 4xx response which will almost certainly result in the connection being closed. There is no fallback within the connection preface process. ALPN allows the client to specify a list of protocols and the server picks the one it wants to use (the server as a list in preference order). If the client doesn't support any of the protocols the server wants to use, the connection fails. Servers that advertise h2 over ALPN do not have to advertise any other HTTP version. Note that all of the above is HTTP/2 specific. If a third protocol was to be supported, it would define how connections to that protocol could be started. >> Were there any other design considerations to support HTTP/2 via upgrade >> protocol mechanisms? My apologies but I didn't find details around this. The Tomcat does doesn't get a choice on how to do this. The available processes to start an HTTP/2 connection are defined by RFC 9113. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
