Internet-Draft: Hypertext Transfer Protocol Version 3 (HTTP/3)

Re:Internet-Draft: Hypertext Transfer Protocol Version 3 (HT... by rqs on Wednesday December 19, 2018 @10:12PM (#18722205)

Wow, just reading this RFC makes my more comfortable compare to reading RFC7540. Possibly because they hided a huge portion of technical details under the keyword QUIC.

I'm not sure I should continue to implement my HTTP/2 server now, as HTTP/3 will overlay almost (as far as I can tell) all the benefit that provided by HTTP/2.

One thing makes me confused though, since:

> The QUIC version being used MUST use TLS version 1.3 or greater as its handshake protocol.

And most TLS 1.3 implementation supports RFC6066, then why:

> .... This may be done using the Server Name Indication (SNI) [RFC6066] extension to TLS <bold>or using some other mechanism</bold>.

? I mean, why include any other mechanism while SNI can do the job?

[ Parent | on HN ]

Re:Internet-Draft: Hypertext Transfer Protocol Version 3 (HT... by p_l on Wednesday December 19, 2018 @11:24PM (#18722501)

I believe SNI had been considered a privacy leak and thus there are calls to replace it?

[ Parent | on HN ]

Re:Internet-Draft: Hypertext Transfer Protocol Version 3 (HT... by anonacct37 on Wednesday December 19, 2018 @11:20PM (#18722480)

Encrypted SNI?

[ Parent | on HN ]

Re:Internet-Draft: Hypertext Transfer Protocol Version 3 (HT... by rqs on Wednesday December 19, 2018 @11:44PM (#18722572)

I will be happy if by "some other mechanism" they meant "Encrypted SNI".

The thing I really don't like to see is that they might eventually keep using the "Host" header and thus potentially creating ambiguity.

[ Parent | on HN ]