Daniel Stenberg wrote: > No, that's plain wrong. *If* it would be sent, it should ask for the correct > protocols in the ALPN field but there won't be any such non-HTTP protocols > specified to use and no servers out there would look for any... >
The ALPN protocol ID registry is available at http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids. "stun.turn" and "stun.nat-discovery" are listed but I think they go beyond the scope of what curl can do. Perhaps in the future there will be more but it would seem pertinent to fix the issue before it leads to bad experiences. RFC 7301 Section 3.2 includes this statement: > In the event that the server supports no protocols that the client > advertises, then the server SHALL respond with a fatal > "no_application_protocol" alert. So curl's behaviour could lead to interop issues, although I would take a chance on saying that non-HTTP servers probably don't currently implement the ALPN TLS extension, silently ignore it and proceed OK. Lucas ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
