6 ms·

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

69 points by yannikyeo 8y ago

sctb 8y ago
Some recent discussions about the proposed HTTP/3 standard: https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18517047 https://news.ycombinator.com/item?id=18517047
teddyh 8y ago
Still no SRV record support. Of course. https://news.ycombinator.com/item?id=15906664#15908696 https://news.ycombinator.com/item?id=15906664#15908696 https://news.ycombinator.com/item?id=8549348#8550133 https://news.ycombinator.com/item?id=8549348#8550133
- skissane 8y ago
  Have any of the people wanting SRV record support in HTTP/3 gone to the working group and proposed it? I searched the working group mailing list and couldn't find any discussion of this topic.
  - floatingatoll 8y ago
    http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/... That’s the final answer for HTTP2. They note as well that, were they to have proceeded, that the SRV record type would be inappropriate regardless and some new type would be needed. Therefore, proposing “SRV” to the HTTP working group for HTTP3 will not succeed. Proposing a new DNS record type might succeed, but it would no longer be called SRV. Based on their reply, I warn you to set your expectations low: proposing a new DNS record type to address their stated concerns would likely take enough time itself that it cannot ship a final RFC in time to be considered for HTTP/3.
    - skissane 8y ago
      From Mark Nottingham's email: > the unfortunate limitations of some DNS gateways/proxies With growth in public DNS services like 8.8.8.8 and 1.1.1.1, plus the advent of DNS-over-HTTPS, I wonder for how much longer that will be a problem.
      - floatingatoll 8y ago
        TLS 1.3 (2006) was held up for months-to-years by the "unfortunate limitations of some TLS gateways/proxies", and PCI compliance only requires TLS 1.1 as of this year (2018 — 12 years later). What solution is available that avoids high-latency additional round-trip requests and would be compatible with today's "unfortunate" gateways and proxies? DNS-over-HTTPS failed for me constantly while traveling, due to captive wifi portals that try to force you into your browser so they can get your Facebook cookie. DNS-over-HTTPS does not necessarily address the round-trip concerns, as it is simply a transport layer for DNS requests and does not guarantee the browser's ability to coalesce plural DNS requests prior to sending them up for resolution. So in light of TLS slowness and DoH unfamiliarity to the marketplace, I personally would expect Mark's described limitations to remain applicable for at least another ten years.
        jupp0r 8y ago
        TLS 1.3 was finalized in August 2018, the first draft is from 2014. [1] [1]: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/ https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/
        floatingatoll 8y ago
        Ugh, too late to fix, but thanks for pointing out the error. It should say TLS 1.1, not 1.3, there.
        deleted 8y ago
        [deleted]
floatingatoll 8y ago
Note that this is draft 17, not a finalized outcome.
- e-m-p 8y ago
  Exactly. This is still a work-in-progress.
moderation 8y ago
For "why not SCTP" please see prior discussions [0] 0. https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=all&dateRange=all&prefix&page=0&sort=byDate https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=a...
- wahern 8y ago
  Odd that (AFAICT) nobody mentions the most obvious and useful feature of SCTP compared to QUIC: SCTP preserves message boundaries. That's immensely useful in almost every scenario other than existing protocols (like HTTP) that reinvent chunking. Building on that, SCTP also supports optional unordered delivery--so reliable but unordered message delivery. I didn't know about this before confirming message boundary preservation with the RFC.
rqs 8y ago
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?
- anonacct37 8y ago
  Encrypted SNI?
  - rqs 8y ago
    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.
- p_l 8y ago
  I believe SNI had been considered a privacy leak and thus there are calls to replace it?
ddtaylor 8y ago
Does anyone know where I could find numbers on how widespread the usage of HTTP2 is?
- vasilia 8y ago
  About 30% of all sites have HTTP/2 support. I don't remember where I saw this. I'm curious why the number is so small because nginx has HTTP/2 out of the box. But if your primary users are using Microsoft IE/Edge I have bad news, this browser has worst HTTP/2 implementation. When we do research on streams prioritization Edge showed that it works like ordinary HTTP/1.1. Safari implementation is based on SPDY, so It has priorities but they never been used in our experiments.
kaspermarstal 8y ago
What typesetting system is this? Is this available somewhere? I love it
- finnthehuman 8y ago
  https://pypi.org/project/xml2rfc/ https://pypi.org/project/xml2rfc/

69 points by yannikyeo 8y ago

sctb 8y ago

Some recent discussions about the proposed HTTP/3 standard: https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18517047 https://news.ycombinator.com/item?id=18517047

teddyh 8y ago

Still no SRV record support. Of course. https://news.ycombinator.com/item?id=15906664#15908696 https://news.ycombinator.com/item?id=15906664#15908696 https://news.ycombinator.com/item?id=8549348#8550133 https://news.ycombinator.com/item?id=8549348#8550133

skissane 8y ago
Have any of the people wanting SRV record support in HTTP/3 gone to the working group and proposed it? I searched the working group mailing list and couldn't find any discussion of this topic.
- floatingatoll 8y ago
  http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/... That’s the final answer for HTTP2. They note as well that, were they to have proceeded, that the SRV record type would be inappropriate regardless and some new type would be needed. Therefore, proposing “SRV” to the HTTP working group for HTTP3 will not succeed. Proposing a new DNS record type might succeed, but it would no longer be called SRV. Based on their reply, I warn you to set your expectations low: proposing a new DNS record type to address their stated concerns would likely take enough time itself that it cannot ship a final RFC in time to be considered for HTTP/3.
  - skissane 8y ago
    From Mark Nottingham's email: > the unfortunate limitations of some DNS gateways/proxies With growth in public DNS services like 8.8.8.8 and 1.1.1.1, plus the advent of DNS-over-HTTPS, I wonder for how much longer that will be a problem.
    - floatingatoll 8y ago
      TLS 1.3 (2006) was held up for months-to-years by the "unfortunate limitations of some TLS gateways/proxies", and PCI compliance only requires TLS 1.1 as of this year (2018 — 12 years later). What solution is available that avoids high-latency additional round-trip requests and would be compatible with today's "unfortunate" gateways and proxies? DNS-over-HTTPS failed for me constantly while traveling, due to captive wifi portals that try to force you into your browser so they can get your Facebook cookie. DNS-over-HTTPS does not necessarily address the round-trip concerns, as it is simply a transport layer for DNS requests and does not guarantee the browser's ability to coalesce plural DNS requests prior to sending them up for resolution. So in light of TLS slowness and DoH unfamiliarity to the marketplace, I personally would expect Mark's described limitations to remain applicable for at least another ten years.
      - jupp0r 8y ago
        TLS 1.3 was finalized in August 2018, the first draft is from 2014. [1] [1]: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/ https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/
        floatingatoll 8y ago
        Ugh, too late to fix, but thanks for pointing out the error. It should say TLS 1.1, not 1.3, there.
      - deleted 8y ago
        [deleted]

floatingatoll 8y ago

Note that this is draft 17, not a finalized outcome.

e-m-p 8y ago
Exactly. This is still a work-in-progress.

moderation 8y ago

For "why not SCTP" please see prior discussions [0] 0. https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=all&dateRange=all&prefix&page=0&sort=byDate https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=a...

wahern 8y ago
Odd that (AFAICT) nobody mentions the most obvious and useful feature of SCTP compared to QUIC: SCTP preserves message boundaries. That's immensely useful in almost every scenario other than existing protocols (like HTTP) that reinvent chunking. Building on that, SCTP also supports optional unordered delivery--so reliable but unordered message delivery. I didn't know about this before confirming message boundary preservation with the RFC.

rqs 8y ago

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?

anonacct37 8y ago
Encrypted SNI?
- rqs 8y ago
  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.
p_l 8y ago
I believe SNI had been considered a privacy leak and thus there are calls to replace it?

ddtaylor 8y ago

Does anyone know where I could find numbers on how widespread the usage of HTTP2 is?

vasilia 8y ago
About 30% of all sites have HTTP/2 support. I don't remember where I saw this. I'm curious why the number is so small because nginx has HTTP/2 out of the box. But if your primary users are using Microsoft IE/Edge I have bad news, this browser has worst HTTP/2 implementation. When we do research on streams prioritization Edge showed that it works like ordinary HTTP/1.1. Safari implementation is based on SPDY, so It has priorities but they never been used in our experiments.

kaspermarstal 8y ago

What typesetting system is this? Is this available somewhere? I love it

finnthehuman 8y ago
https://pypi.org/project/xml2rfc/ https://pypi.org/project/xml2rfc/