Thank you! On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt <foo...@chromium.org> wrote:
> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano <yhir...@chromium.org> wrote: > >> >> >> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt <foo...@chromium.org> >> wrote: >> >>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhir...@chromium.org> >>> wrote: >>> >>>> Hi Philip, >>>> >>>> Sorry for the belated reply. Comments inline: >>>> >>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt <foo...@chromium.org> >>>> wrote: >>>> >>>>> Hi again, >>>>> >>>>> I've made a full pass of the intent now. I have a lot of questions, >>>>> but am pretty convinced we should ship this, it's just a matter of what >>>>> things need to block that, and what things can be left until later. >>>>> >>>>> Comments inline... >>>>> >>>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano <yhir...@chromium.org> >>>>> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> yhir...@chromium.org, vasi...@chromium.org >>>>>> >>>>>> Explainer >>>>>> >>>>>> https://github.com/w3c/webtransport/blob/main/explainer.md >>>>>> >>>>>> Specification >>>>>> >>>>>> https://w3c.github.io/webtransport >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/ >>>>>> >>>>> >>>>> I skimmed https://github.com/w3c/webtransport/issues/ and see >>>>> multiple issues filed by other browser vendors. Are any of the remaining >>>>> issues ones that could change the API's shape or behavior? It would be >>>>> good >>>>> to resolve any such issues, since they won't be possible to address once >>>>> the API is locked in by sites depending on it. >>>>> >>>>> >>>> I believe we've addressed issues that may require breaking changes. You >>>> can see open <https://github.com/w3c/webtransport/milestone/1>/closed >>>> <https://github.com/w3c/webtransport/milestone/1?closed=1> issues for >>>> the initial launch (this intent). I shared our plan >>>> <https://docs.google.com/document/d/1X9-a03rtm0FqTW01nG6e7f91NAguGEv37mP964HrJlk/edit#heading=h.v9yxozj8naro> >>>> at a WG meeting in May >>>> <https://www.w3.org/wiki/WebTransport/Meetings#WebTransport_Bi-weekly_Virtual_Meeting_.2316_late_-_May_25.2C_2021> >>>> and >>>> we've been working to find and resolve such issues since then. >>>> >>> >>> I see, creating a milestone for this is really handy! Are the remaining >>> issue in https://github.com/w3c/webtransport/milestone/1 not blocking >>> then, even issue #349 <https://github.com/w3c/webtransport/issues/349>? >>> >> >> *Except for issue #349* we have consensus on discussions. As Victor >> commented in this thread, we can ship WebTransport *except for * >> customeCertificationHashes >> <https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes> >> if >> needed. >> > > If custom certificates is a nice-to-have then shipping without it seems > fine to me. That would mean removing serverCertificateHashes from the > dictionary, right? I ask because the spec also says something > about NotSupportedError when the protocol doesn't support it, but it seems > better to behave as if the feature doesn't exist at all. > > The property is protected by WebTransportCustomCertificates <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webtransport/web_transport_options.idl>, so when we enable only WebTransport, the property will be invisible. > Looking through some other issues: > > - Can https://github.com/w3c/webtransport/issues/59 be resolved for > the WebPKI case? If CSP currently has no effect, then adding it on later > could be hard because some sites could already be using CSP that would > block it, and those sites would be broken by adding CSP support later. > > Yes I think so. We check the "connect-src" directive. It is tested as csp-fail.https.window.js <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-fail.https.window.js> and csp-pass.window.js <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-pass.https.window.js> . > - https://github.com/w3c/webtransport/issues/175 sounds editorial but > doesn't have that label. If any code would change as a result of fixing it, > should this be done before shipping? > > I think this is to describe our current protection and won't affect implementation. > > - https://github.com/w3c/webtransport/issues/236 has no discussion, > could it have any impact on implementation? > > This is about how to describe algorithms in the spec in terms of threading, and this won't impact implementation. > > - > > Having consensus on the issues is great, but some things are still much > harder to fix after shipping, or harder to get prioritized after shipping, > so that's why I'm asking. > > Activation >>>>>> >>>>>> Since UDP is often blocked on the network, the developers have to >>>>>> assume that the API often would not work even in the situations when it >>>>>> is >>>>>> implemented in the browser. >>>>>> >>>>> >>>>> This is interesting. How do web developers detect and deal with this >>>>> situation, and distinguish it from the network temporarily going down? >>>>> I've >>>>> skimmed https://web.dev/webtransport/ and it doesn't mention this >>>>> kind of blocking, does this need to be highlighted in documentation and >>>>> reference docs for WebTransport? >>>>> >>>> >>>> For usual loading browsers detect the network conditions and choose the >>>> right version (HTTP/3, HTTP/2 and HTTP/1.1). We may be able to do similar >>>> things in the future (on the other hand, we may end up asking web >>>> developers to detect it). Some people are working on WebTransport over >>>> HTTP/2 <https://github.com/ietf-wg-webtrans/draft-webtransport-http2>. >>>> >>> >>> With the implementation as it is now, what will the behavior be on a >>> network where UDP is blocked? Presumably the initial connection that serves >>> HTML and scripts has then been negotiated to HTTP/2 or HTTP/1.1, but is >>> there any indication in the API that WebTransport is going to fail ahead of >>> time, or error that can be distinguished from an intermittent network >>> error? I'm thinking of the code to fall back to WebSockets that might be >>> necessary here, how one would determine that the fallback is needed. >>> >> >> To prevent malicious web developers from sniffing the network conditions, >> we don't expose detailed network error information to web developers when >> session establishment fails. >> So currently web developers can 1) retry establishing a session with a >> fallback protocol (e.g., WebSocket), or 2) race two (or more?) session >> establishment operations. >> Of course, web apps can use other information such as the results of past >> attempts, geolocation information, and so on. >> >> The current way is very primitive, and we may be able to provide more >> sophisticated means in the future. >> > > I see, that's unfortunate but makes sense. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6Gcyn8x3pCHOZtdEvjY_s9mugfNWzxOyeRDs_kXFvO79g%40mail.gmail.com.
