I searched for an issue to track progress of implementing HTTP/3 in the standard library but couldn't find one, so I'm opening this new issue to track this (presumably inevitable) effort.
AlvaroVasconcelos
All 5 comments
@Irhn
given that
- http/3 draft has been published last month
- chrome is deploying it
- on safari is even enabled by default (source)
What are the plans for Dart's implementation?
Will it be a separate package like http2 or grpc?
Any timeline for a release?
iapicca
on 20 Oct 2020
There are currently no plans (or bandwidth) to implement HTTP/3 support as either builtin dart:io feature or even as a package.
@lrhn do you think we should maybe close this as not planned to reflect the current thinking around dart:io and networking package priorities?
/cc @mit-mit @a-siva
mraleph
on 20 Oct 2020
Not sure closing is the right thing to do. When HTTP/3 becomes a stable standard, we will most likely have to implement it.
We are just not going to be riding the bleeding edge and implement the draft specification.
It's unlikely that there will be any clients or back-ends which will be HTTP/3 only, so falling back on HTTP/2 is a valid option.
So, keeping this open as a place where people needing the feature can weigh in, but with no near-time plans to do an implementation in Dart.
It's a non-trivial piece of networking code, especially for the server code, so we'll have to ensure we have someone qualified to implement it when the time comes. At that time, we can figure out whether we want it in a separate package or not.
lrhn
on 20 Oct 2020
What about the quic protocol in general, apart from HTTP/3?
gargakshit
on 20 Oct 2020
There have already had https://tools.ietf.org/html/draft-ietf-quic-transport-32. It's a really nice package that the Dart SDK should have.
lovung
on 1 Dec 2020
Related issues
rinick
路
3Comments
bergwerf
路
3Comments
DartBot
路
3Comments
ranquild
路
3Comments
Hixie
路
3Comments
Most helpful comment
Not sure closing is the right thing to do. When HTTP/3 becomes a stable standard, we will most likely have to implement it.
We are just not going to be riding the bleeding edge and implement the draft specification.
It's unlikely that there will be any clients or back-ends which will be HTTP/3 only, so falling back on HTTP/2 is a valid option.
So, keeping this open as a place where people needing the feature can weigh in, but with no near-time plans to do an implementation in Dart.
It's a non-trivial piece of networking code, especially for the server code, so we'll have to ensure we have someone qualified to implement it when the time comes. At that time, we can figure out whether we want it in a separate package or not.