{"push_id":965093489,"size":1,"distinct_size":1,"ref":"refs/heads/h2c_upgrade_efficiency","head":"2c5a4310837f4b5c854b208494c4596f5f924217","before":"a82268149ab3b08d261d4a72988f86e2f8b3ef23","commits":[{"sha":"2c5a4310837f4b5c854b208494c4596f5f924217","author":{"email":"5da16fcbbd974f7664efef57890c0e4a0c3f1c65@linecorp.com","name":"Trustin Lee"},"message":"More efficient and correct H1C-to-H2C upgrade\n\nMotivation:\n\nThe current HTTP/1-to-2 upgrade has the following slightly inter-related\nissues:\n\n1. When a user specifies an explicit session protocol (H1C/H1/H2C/H2)\ninstead of HTTP/HTTPS, the session creation must fail when the\nnegotiated protocol does not match exactly. For example, when a user\nspecified H2C, a rejected upgrade request should fail session creation.\n2. When connecting to a host whose name is registered in /etc/hosts, the\n'Host' header of the HEAD upgrade request is not set to the host name\nbut the host address.\n3. When a user specifies HTTP/HTTPS as session protocol and the remote\nhost does not support H2C/H2, the client currently keeps sending the\nHEAD upgrade request. We could cache the list of the hosts with no\nHTTP/2 support, so we do not send upgrade requests unnecessarily.\n4. Some servers send 'Connection: close' header when rejecting a upgrade\nrequest, resulting disconnection. When this happens and a user specified\nHTTP as session protocol, the client should retry the connection attempt\nsilently, so that a user does not notice the upgrade failure, because\nit's not really a failure.\n\nModifications:\n\n- (2) Fork DefaultHostsFileEntryResolver and HostsFileParser so that\n  they do not omit the host name in the resolved InetAddress, where\n  the host name is picked up from by Armeria\n- (1) Add SessionProtocolNegotiationException\n  - Mark the session creation as failure when protocol upgrade fails or\n    the protocol is different from what user expected\n    - See HttpConfigurator and HttpSessionChannelFactory\n- (3) Add SessionProtocolNegotiationCache\n  - Update the cache when protocol upgrade is rejected by remote host in\n    HttpConfigurator\n- (4) HttpSessionChannelFactory now retries the connection attempt when\n  HttpConfigurator finds the upgrade response contains 'Connection:\n  close' header.\n- Add the test cases for (1, 3, 4) to ThriftOverHttpClientTServletIntegrationTest\n- Miscellaneous:\n  - When HTTP codec fails to decode a response, use the cause of the\n    decoder failure as the invocation result, which is much more\n    informative.\n  - Add another variant of Exceptions.logIfUnexpected()\n  - Add Exceptions.clearTrace() to remove the stack trace of an\n    exception easily\n  - Fix a bug where HttpServerHandler sends content in a response to a\n    HEAD request. A response content of a HEAD request must be empty.\n  - Upgrade jetty-alpn-agent to 1.0.1.Final to support JDK 8u71/72\n\nResult:\n\n- Invocation now fails when the negotiated protocol does not match the\n  desired protocol.\n- The 'Host' header in a upgrade request now contains host name even if\n  the host address was resolved via the /etc/hosts file\n- HTTP/1-to-2 upgrade request is sent only when necessary.\n- Http/1-to-2 upgrade deals better with 'Connection: close' headers.","distinct":true,"url":"https://api.github.com/repos/trustin/armeria/commits/2c5a4310837f4b5c854b208494c4596f5f924217"}]}