The Google's approach is keeping connection and expecting the client continues to speak http/1.1 as a fail-back protocol. This is one approach but I don't think it is all the cases.
For example when a server only provides a service that binds to the specific protocol or tests some experimental protocols over TLS, the server does not need to keep the connection and closes it in the case of no matching because there are no fail-back protocol. It is natural for a server to send a no_application_protocol alert to notify its error to the client before closing as well as it does in handshake_failure. According to RFC7301 it is defined SHALL so that the client which is implemented with the spec properly can recognize the alert correctly. I look back my patch now and it was really old and needs some changes. If it would be accepted, I'd like to revise it. On 2015/06/13 23:02, Rich Salz via RT wrote: > So, the google approach is that if no protocol match is found, the server > replies WITHOUT the alpn header. They don't like no_app_protocol, to put it > mildly :) > > thoughts? > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
