Linux: add next-protocol-negotiation to libssl.

net/base/ssl_config_service.h

Index: net/base/ssl_config_service.h
diff --git a/net/base/ssl_config_service.h b/net/base/ssl_config_service.h
index a4d3cb476bdf55cc9bfd92135cbf8c5a744a6b65..45c1fc6f3368f26f1197510d57cf6726b8317ef5 100644
--- a/net/base/ssl_config_service.h
+++ b/net/base/ssl_config_service.h
@@ -18,7 +18,8 @@ struct SSLConfig {
   // Default to SSL 2.0 off, SSL 3.0 on, and TLS 1.0 on.
   SSLConfig()

[willchan no longer on Chromium, 2009/11/25 19:48:13]

I think might be getting to the point where making a .cc file and putting the
constructor and destructor definition there make sense, since the inline
constructor and destructor is starting to get large with the inline constructors
and destructors for the std::vector<> and std::string members.  Perhaps this is
premature optimization.  I leave the choice up to you.

       : rev_checking_enabled(true),  ssl2_enabled(false), ssl3_enabled(true),
-        tls1_enabled(true), send_client_cert(false), verify_ev_cert(false) {
+        tls1_enabled(true), send_client_cert(false), verify_ev_cert(false),
+        next_protos("\007http1.1") {
   }
 
   bool rev_checking_enabled;  // True if server certificate revocation
@@ -57,6 +58,14 @@ struct SSLConfig {
 
   bool verify_ev_cert;  // True if we should verify the certificate for EV.
 
+  // The list of application level protocols supported. If set, this will
+  // enable Next Protocol Negotiation (if supported). This is a list of 8-bit
+  // length prefixed strings. The order of the protocols doesn't matter expect
+  // for one case: if the server supports Next Protocol Negotiation, but there
+  // is no overlap between the server's and client's protocol sets, then the
+  // first protocol in this list will be requested by the client.
+  std::string next_protos;
+
   scoped_refptr<X509Certificate> client_cert;
 };