- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 25 Jan 2015 21:37:41 +1300
- To: Martin Thomson <martin.thomson@gmail.com>, Adrien de Croy <adrien@qbik.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 25/01/2015 6:20 p.m., Martin Thomson wrote: > On 24 January 2015 at 19:33, Adrien de Croy wrote: >> The problem for me as a proxy implementor, is I still don't know whether to >> expect there to be a TLS layer in there or not. Please don't make me resort >> to sniffing or daft heuristics to figure this out. Just make it explicit. >> If there is an and/or option, include a way to clearly state this in the >> protocol. > > The ALPN identifier tells you if there is TLS. > What does this mean? CONNECT example.com:443 HTTP/1.1 Tunnel-Protocol: h2c ... <TLS handshake ALPN(h2)> Or CONNECT example.com:80 HTTP/1.1 Tunnel-Protocol: HTTP/1.1 ... <TLS handshake ALPN(http/1.1)> GET / HTTP/1.1 Or CONNECT example.com:80 HTTP/1.1 Tunnel-Protocol: HTTP/1.1 \r\n <TLS handshake> ... HTTP/1.1 4xx Protocol Not Supported \r\n The "HTTP/1.1" protocol is not permitted through this HTTP/1.1 proxy. \r\n Or CONNECT example.com:587 HTTP/1.1 Tunnel-Protocol: h2c ... <TLS handshake> HELO example.com:25 HTTP/1.1 ... Any attempt to proxy the above and use the new header results in some form of interoperability failures. So what reason does anybody have to bother using it? Lots of problems disappear by being strict that next means *next* layer. Not allowing any intermediary layer (ie TLS ALPN extension) to contradict the identifiable state. Amos
Received on Sunday, 25 January 2015 08:38:16 UTC