Hello, We conducted an experiment for Early Hints (chromestatus <https://chromestatus.com/feature/5207422375297024>) with partners in Q3 - Q4, 2021. The experiment data suggests that the performance impact is highly positive. Based on these insights, we are confident that Early Hints will be a viable alternative to H/2 Push for performance use cases. In addition, by design Early Hints will not run into the overpushing concerns that bogged down H/2 Push. We are working with some of our partners to share a bit more details.
Next steps (for Early Hints) We are actively working on finalizing the shipping plan / timeline. In particular, Early Hints requires updating multiple specs. Once our plan becomes clearer, the details will be shared on a new Intent to Ship thread. Non performance use cases For other perceived use cases beyond performance improvements, we recommend sharing more details over at WICG Discourse <https://discourse.wicg.io/> with a focus on the problem you are trying to solve rather than how H/2 Push could be used. In addition, if you currently rely on H/2 Push in ways that Early Hints can’t address, please share details <https://discourse.wicg.io/> about how critical this is to your product/service, on top of your use case. Thanks Daisuke On Sun, Feb 20, 2022 at 6:40 PM Morgaine <rekt...@gmail.com> wrote: > I'm not sure if you are being deliberately cruel & malicious, or just > accidentally cruel. Web developers have been begging for Fetch to please > for the love of everything holy please report HTTP PUSH responses for 3/4 > of a decade now, so we might implement Webpush Protocol or other similar > reactive techniques via using Push. There have been a couple explorations > of this, but after a series of proposals, nothing has materialized, nothing > has developed. Rather than ever making PUSH useful, rather than acknowledge > that PUSH could implement a reactive, Webpush Protocl like system, you seem > intent on using negligence to destroy the baby before it has a chance. This > has been requested & begged for, there's been a couple spins, but you seem > ready to destroy possibility in this deprecation, before even having made > the most minimum bid to make the technology useful. Please, heed > https://github.com/whatwg/fetch/issues/51 & try to do some little bit of > good in the world, before you go running off macabely destroying > possibility. > > Chrome had a number of attempts where some good responsible smart > actually-know-something developers saw that PUSH could be useful, and > proposed trying to make Fetch spec be useful, proposed making PUSH useful. > That the current crop of developers doesn't understand & see this > possibility, either denies or is ignorant to the sad long history of > begging, pretty please, to let us observe & react to PUSH requests, is a > tragedy. We are headed for using HTTP3-over-WebTransport, because ya'll are > sending in the wrecking ball, rather than following up & doing the bear > minimum, most essential, most basic spec-authoring work on Fetch, that was > begged for, pleaded for, for 3/4 of a decade now. This is such a sad sad > route, and it's going to be such a gross boondogle working around the > apathy browser developers gave for PUSH, their unlove, their incapability > to provide even some simple basic capabilities to use PUSH. > https://github.com/whatwg/fetch/issues/51 needed some love. It still > does. Turn the ship around. Do the minimum viable feature, before you > decide to axe it. You might even be able to not put the PUSH into cache, if > that makes you happy, so long as you provide an alternative means to > receive the PUSH responses to a Fetch. Doing nothing, permitting nothing: > that's such a misdeed. Please, again, don't do this. And don't tell us > something that is deeply related, that is at the heart of this disaster, > that has gone unaddressed & unimprove for so long, is unrelated. > On Wednesday, June 30, 2021 at 9:42:26 AM UTC-4 las...@chromium.org wrote: > >> No, the Push API ( >> https://developer.mozilla.org/en-US/docs/Web/API/Push_API) is entirely >> unrelated other than the name. >> >> -Brad >> >> On Wed, Jun 30, 2021, 9:00 AM Vito De Giosa <vito.d...@gmail.com> wrote: >> >>> Does it mean that also that the webpush protocol, Push Api won't work >>> anymore? >> >> >>> >>> On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org wrote: >>> >>>> It feels like there are a lot of different things going on here and it >>>> might be useful to unpack it a bit. >>>> >>>> Web Vitals thresholds - they aren't a hard line where you pass or you >>>> don't. The last updates from the team explained that each metric is looked >>>> at independently and there is a progressive boost in the "needs >>>> improvement" zone based on how close a given URL is to the "good" >>>> threshold. That doesn't really help if you're being held to the "number of >>>> URLs that need improvement" in the search console but there is not much >>>> practical difference between a 2.6 and a 2.5 LCP (not like the cliff that >>>> it initially sounded like it would be). >>>> >>>> Layout Shifts from late-loading fonts - Using PUSH to try to fix this >>>> race condition feels like the wrong tool for the job. Even with >>>> font-display: block it is possible that a text element won't be sized >>>> correctly until the font loads, causing something after it in the DOM to be >>>> moved. Preload can help get the font loaded sooner so it will be there at >>>> layout time more often but it will still be racy. PUSH is also still racy >>>> but makes it even more likely that the font will be there early but at the >>>> cost of delaying literally everything else (including the HTML in a lot of >>>> cases). It feels like we need a better primitive to tell the browser to >>>> block layout until the text sizes are known (if that is something a site >>>> wants to do) so that things can still load asynchronously but the rendering >>>> can be controlled. It's a lot like CSS blocking layout/render - otherwise >>>> unstyled content is flashed for FOUC. font-display: block prevents the >>>> render of text in the wrong font but nothing lets you block incorrect >>>> layout (that I know of). Fixing that properly rather than wedging fonts >>>> ahead of everything else is a better fix. >>>> >>>> Push sounds like a great solution, particularly when it can be done >>>> intelligently to not push resources already in cache and if it can exactly >>>> only fill the wait time while a CDN edge goes back to an origin for the >>>> HTML but getting those conditions right in practice is extremely rare. In >>>> virtually every case I have seen, the pushed resources end up delaying the >>>> HTML itself, the CSS and other render-blocking resources. Delaying the HTML >>>> is particularly bad because it delays the browser's discovery of all of the >>>> other resources on the page. Preload works with the normal document >>>> parsing and resource discovery, letting preloaded resources intermix with >>>> other important resources and giving the dev, browsers and origins more >>>> control over prioritization. >>>> >>>> On Friday, June 25, 2021 at 7:32:05 PM UTC-4 Brad Lassey wrote: >>>> >>>>> On Fri, Jun 25, 2021, 6:58 PM Andrew Wilder <and...@andrewwilder.com> >>>>> wrote: >>>>> >>>>>> Interesting, thanks Brad. >>>>>> >>>>>> I'd imagine that the performance benefit is actually greater for >>>>>> sites that don't use a CDN at all, since one RT is likely to take much >>>>>> longer >>>>>> >>>>> Due to initial window sizes, one RT worth of data is measured in >>>>> bytes, not time and does not vary based on round trip times. >>>>> >>>>>> ... so if you're only looking at CDNs, that might explain part of the >>>>>> difference? >>>>>> >>>>> >>>>> We looked at all sites that were using Push, but in addition cut the >>>>> data by CDN to look for correlations. >>>>> >>>>>> >>>>>> With the extremely tight requirements of Core Web Vitals, one >>>>>> round-trip's time potentially *could* make a significant difference >>>>>> in some cases. I was recently working on a site where I just couldn't >>>>>> get >>>>>> the Largest Contentful Paint metric to pass the 75th percentile of 2.5s >>>>>> in >>>>>> CRuX. I was stuck, soooo close, at 2.6s. (And it was testing great in >>>>>> Lab >>>>>> Data...just not in the field data, frustratingly) >>>>>> >>>>> I'd suggest you look at how big your initial resources are and what's >>>>> left over after the initial window. Again, the reference to a round trip >>>>> is >>>>> to the amount of data, not time. >>>>> >>>>> >>>>>> A roundtrip can take well over 100ms, so that alone could be enough >>>>>> to shave off 0.1s under the right conditions, or maybe more, to get the >>>>>> site to pass CWV. But I also stopped short of actually bothering >>>>>> to implement and test this when I saw this thread (I wasn't even sure if >>>>>> Chrome was still working for Server Push or not -- though I see that was >>>>>> answered a few messages back.) >>>>>> >>>>>> I don't think I would have argued this point before core web vitals, >>>>>> since one round-trip does seem nearly negligible -- but because now we >>>>>> have >>>>>> *absolute* metrics we need to hit, which are pretty tough in some >>>>>> cases, I think keeping this one additional tool in the toolbelt may be >>>>>> worthwhile... >>>>>> >>>>>> Thanks again, >>>>>> Andrew >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 25, 2021 at 3:28 PM Brad Lassey <las...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On Fri, Jun 25, 2021, 4:53 PM Andrew Wilder <and...@andrewwilder.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Brad, thanks for the clarification. We're definitely utilizing >>>>>>>> preload -- that's pretty much "table stakes" for passing Core Web >>>>>>>> Vitals at >>>>>>>> this point. We're also utilizing many other tools, including Critical >>>>>>>> Path >>>>>>>> CSS and delaying JavaScript until after user interaction. Those are far >>>>>>>> more complicated to implement properly than Server Push (especially >>>>>>>> with >>>>>>>> Cloudflare's excellent implementation, as Francesco pointed out). >>>>>>>> >>>>>>>> The new Page Experience requirements from Google have changed the >>>>>>>> game when it comes to site speed. Previously, speed was known to be a >>>>>>>> ranking factor, but the details were secret, and it was more of a >>>>>>>> "relative" factor compared to the competition. "Just be faster than >>>>>>>> your >>>>>>>> competition" was sufficient before. >>>>>>>> >>>>>>>> But with Core Web Vitals, the requirements are now absolute >>>>>>>> criteria, and it's pass/fail regardless of other sites in your >>>>>>>> vertical. >>>>>>>> There's no gray area here -- and for many sites, passing all three CWV >>>>>>>> criteria, while keeping the features that site owners need, is quite >>>>>>>> challenging. >>>>>>>> >>>>>>>> Furthermore, you mentioned "this depreciation represents a low risk >>>>>>>> of web breakage." But keeping Server Push is not detrimental - it has >>>>>>>> *zero >>>>>>>> risk* of web breakage. So why remove support for it? >>>>>>>> >>>>>>>> So it seems we have one department of Google (Search) pushing for a >>>>>>>> faster web, and another Department (Chrome) considering taking away a >>>>>>>> tool >>>>>>>> that, with proper implementation, should actually help achieve that >>>>>>>> goal. >>>>>>>> >>>>>>>> Having said that, the truly important question that we're kind of >>>>>>>> dancing around is:* Is Server Push actually beneficial? * >>>>>>>> >>>>>>>> If the answer to that is "yes," then I think it's better for Chrome >>>>>>>> to keep supporting it -- and, instead of killing it, to make efforts to >>>>>>>> increase adoption. >>>>>>>> >>>>>>>> But if you're able to demonstrate that, when properly implemented, >>>>>>>> it has no *actual *speed/CWV benefits compared to using <preload> >>>>>>>> links in the <head>, I'll be grateful because it means I don't have to >>>>>>>> spend time finding that out on my own. :) >>>>>>>> >>>>>>> Our data shows that it is not providing a speed benefit in practice >>>>>>> and in fact is an overall slight performance regression for Chrome >>>>>>> users. >>>>>>> >>>>>>> As far as differentiating "proper" use versus naive use, I cut the >>>>>>> data by which CDN hosted each domain and didn't see any one CDN with a >>>>>>> net >>>>>>> performance benefit, which I interpret as not indicating that there is >>>>>>> necessarily a proper vs improper way to use the feature. This >>>>>>> intuitively >>>>>>> makes sense as the theoretical potential benefit over preload is >>>>>>> vanishingly small (1 RT worth of data minus your initial resource) and >>>>>>> depending on the situation very possibly nil, versus the relatively high >>>>>>> penalty of pushing the wrong thing. >>>>>>> >>>>>>> >>>>>>>> Thanks again, >>>>>>>> Andrew >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 25, 2021 at 1:25 PM Francesco Montanari < >>>>>>>> francesco...@outlook.com> wrote: >>>>>>>> >>>>>>>>> It's not necessarily complex to implement for the developer. >>>>>>>>> For example, Cloudflare gives it by default, you just need to add >>>>>>>>> the HTTP preload header ( >>>>>>>>> https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/ >>>>>>>>> ) >>>>>>>>> and they have a smart implementation of it, they push assets only >>>>>>>>> at the first visit, they don't push them again when they know the >>>>>>>>> browser >>>>>>>>> should have it already in its cache. >>>>>>>>> >>>>>>>>> They also were the first to offer SSL for free to everyone in >>>>>>>>> 2014, and today nobody would pay for a SSL cert. So good things take >>>>>>>>> time >>>>>>>>> to spread... >>>>>>>>> >>>>>>>>> It's just a matter of time, when the WordPress themes start adding >>>>>>>>> the preload HTTP header for their resources (it's a one-liner in >>>>>>>>> PHP), all >>>>>>>>> the wordpress sites which are on cloudflare will automatically have >>>>>>>>> HTTP >>>>>>>>> push with zero configuration, and the usage stats will rise as well. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Friday, 25 June 2021 at 22:58:41 UTC+3 las...@chromium.org >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Andrew, >>>>>>>>>> I just want to clarify one point, we are proposing to depreciate >>>>>>>>>> and remove HTTP Push because it has not proven to provide performance >>>>>>>>>> benefits over other, less complex and technically burdensome >>>>>>>>>> techniques >>>>>>>>>> such as preload (which I would encourage you to look at if you >>>>>>>>>> haven't >>>>>>>>>> already). The discussion of the amount of usage of Push is largely >>>>>>>>>> making >>>>>>>>>> the case that this depreciation represents a low risk of web >>>>>>>>>> breakage. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Brad >>>>>>>>>> >>>>>>>>>> On Fri, Jun 25, 2021, 1:08 PM Andrew Wilder < >>>>>>>>>> and...@andrewwilder.com> wrote: >>>>>>>>>> >>>>>>>>>>> Sorry, I meant to say that Origin Summary CLS is just over 0.10, >>>>>>>>>>> and/or LCP is 2.6s or 2.7s. Just wanted to clear that up so you >>>>>>>>>>> don't >>>>>>>>>>> think I don't know what I'm talking about! 😉 >>>>>>>>>>> >>>>>>>>>>> On Friday, June 25, 2021 at 10:02:13 AM UTC-7 Andrew Wilder >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I run an agency that supports and maintains over 500 WordPress >>>>>>>>>>>> sites -- and we do a lot of site speed optimization work. Most of >>>>>>>>>>>> them are >>>>>>>>>>>> food blogs, and because of their complexity, it's very difficult >>>>>>>>>>>> to get >>>>>>>>>>>> them to pass the three Core Web Vitals requirements (especially >>>>>>>>>>>> LCP and >>>>>>>>>>>> CLS). >>>>>>>>>>>> >>>>>>>>>>>> I've been experimenting with Server Push as a way to get assets >>>>>>>>>>>> loaded faster -- especially web fonts, which are often a source of >>>>>>>>>>>> shifts, >>>>>>>>>>>> as they switch from the default fallback font to the web font. >>>>>>>>>>>> Often we run >>>>>>>>>>>> into situations where the Origin Summary CLS is 2.6 or 2.7 >>>>>>>>>>>> seconds. Being >>>>>>>>>>>> able to get fonts loaded earlier may help prevent shifts as they >>>>>>>>>>>> load; or >>>>>>>>>>>> to shave off even 0.1 second for the LCP element (especially if >>>>>>>>>>>> it's an >>>>>>>>>>>> image) may be enough to get the site to pass CWV completely. >>>>>>>>>>>> >>>>>>>>>>>> On some sites we exhausted other ways to speed things up to >>>>>>>>>>>> pass CWV, and it was starting to look like Server Push might be >>>>>>>>>>>> able to get >>>>>>>>>>>> us across the finish line. But I paused on getting further into >>>>>>>>>>>> development >>>>>>>>>>>> on this, because I found this thread! Unfortunately, you're now >>>>>>>>>>>> creating a >>>>>>>>>>>> self-fulfilling prophecy of killing off Server Push. By >>>>>>>>>>>> announcing that >>>>>>>>>>>> you're considering removing it -- primarily because not enough >>>>>>>>>>>> people use >>>>>>>>>>>> it -- you're discouraging further people to start using it! Oh, >>>>>>>>>>>> the irony. >>>>>>>>>>>> >>>>>>>>>>>> Considering Google's push on site speed and Core Web Vitals, it >>>>>>>>>>>> seems quite contradictory for you to disable Server Push. Instead, >>>>>>>>>>>> it would >>>>>>>>>>>> be far better to invest more resources into helping people utilize >>>>>>>>>>>> it -- >>>>>>>>>>>> and making it more effective to help improve speed and user >>>>>>>>>>>> experience. >>>>>>>>>>>> >>>>>>>>>>>> On Friday, June 25, 2021 at 8:45:09 AM UTC-7 Maxim Makarov >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Please don't remove HTTP/2 Server Push support >>>>>>>>>>>>> >>>>>>>>>>>>> On Monday, June 21, 2021 at 5:32:25 PM UTC+3 b...@chromium.org >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Francesco, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Responding to the first part of your email only: no, HTTP/2 >>>>>>>>>>>>>> push is currently not disabled by default or removed from >>>>>>>>>>>>>> Chrome. However, >>>>>>>>>>>>>> there is a 1% holdback experiment running on Stable channel to >>>>>>>>>>>>>> allow >>>>>>>>>>>>>> monitoring of *hypothetical* performance benefits. If push does >>>>>>>>>>>>>> not work >>>>>>>>>>>>>> for you, your browser session might have been randomly assigned >>>>>>>>>>>>>> to the >>>>>>>>>>>>>> experiment. In that case, restarting Chrome will fix it (with >>>>>>>>>>>>>> 99% >>>>>>>>>>>>>> probability). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bence >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 19, 2021 at 3:58 PM Francesco Montanari < >>>>>>>>>>>>>> francesco...@outlook.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it already removed? I've implemented it but it doesn't >>>>>>>>>>>>>>> seem to work in Chrome. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyway, please don't kill it. >>>>>>>>>>>>>>> Now that Google Search is deploying the "web vitals" update, >>>>>>>>>>>>>>> which makes the loading speed a key factor for ranking, more >>>>>>>>>>>>>>> and more >>>>>>>>>>>>>>> developers are working to improve the sites speed, and pushing >>>>>>>>>>>>>>> key assets >>>>>>>>>>>>>>> would be very helpful. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Monday, 7 June 2021 at 23:25:02 UTC+3 rektide wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Dec 30, 2020 at 2:11 PM Brad Lassey < >>>>>>>>>>>>>>>> las...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Dec 23, 2020 at 10:25 PM Morgaine < >>>>>>>>>>>>>>>>> rek...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I stated in the very first reply to this thread, it is >>>>>>>>>>>>>>>>>> a horrific tragedy that the situation is like this. It's >>>>>>>>>>>>>>>>>> been HALF A DECADE >>>>>>>>>>>>>>>>>> OF IGNORING DEVELOPERS on >>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/65 and >>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/607 , who have >>>>>>>>>>>>>>>>>> begged for fetch to support push, have BEGGED, & gotten no >>>>>>>>>>>>>>>>>> where. To say >>>>>>>>>>>>>>>>>> that the fetch spec does not mention push is to spit in our >>>>>>>>>>>>>>>>>> faces. This is >>>>>>>>>>>>>>>>>> farce & tragedy. Perhaps it's only ignorance you speak from, >>>>>>>>>>>>>>>>>> but I can not >>>>>>>>>>>>>>>>>> be more hurt to hear you say this. I have repeated time & >>>>>>>>>>>>>>>>>> time again in >>>>>>>>>>>>>>>>>> countless threads the desires for fetch to PLEASE FOR THE >>>>>>>>>>>>>>>>>> LOVE OF GOD >>>>>>>>>>>>>>>>>> support fetch. It's insulting that there has been zero >>>>>>>>>>>>>>>>>> progress. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am sorry that my words had this effect on you. I believe >>>>>>>>>>>>>>>>> the use cases that you've articulated are being addressed >>>>>>>>>>>>>>>>> with WebTransport >>>>>>>>>>>>>>>>> (https://github.com/w3c/webtransport/). If you don't >>>>>>>>>>>>>>>>> believe so, can you file issues there to make sure they are >>>>>>>>>>>>>>>>> properly >>>>>>>>>>>>>>>>> considered? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems farcical to me that we are going to need to run >>>>>>>>>>>>>>>> HTTP3 over WebTransport to get a usable implementation of Push. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The browser should be good at HTTP. We should have these >>>>>>>>>>>>>>>> capabilities. Deciding to make everyone invent and bring their >>>>>>>>>>>>>>>> own userland >>>>>>>>>>>>>>>> WebTransport stack to be able to tell that an HTTP resource >>>>>>>>>>>>>>>> was pushed is a >>>>>>>>>>>>>>>> huge waste of bandwidth to send that userland stack, & a >>>>>>>>>>>>>>>> colossal mass of >>>>>>>>>>>>>>>> complexity to do the tunneling, & generates a far far more >>>>>>>>>>>>>>>> complex >>>>>>>>>>>>>>>> networking situation than if the browser would implement the >>>>>>>>>>>>>>>> one optional >>>>>>>>>>>>>>>> part of HTTP. Where-as before an a service might have run on >>>>>>>>>>>>>>>> HTTP3, pushed >>>>>>>>>>>>>>>> a resource, & seen it arrive, the service must host an >>>>>>>>>>>>>>>> WebTransport tunnel >>>>>>>>>>>>>>>> that carries HTTP3 inside of it. Now we have to worry about >>>>>>>>>>>>>>>> X-Forwarded-For >>>>>>>>>>>>>>>> like concerns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebPush Protocol already takes advantage of these >>>>>>>>>>>>>>>> capabilities, for example, to create a simple to implement, >>>>>>>>>>>>>>>> elegant >>>>>>>>>>>>>>>> notification service, used by all browsers: but without the >>>>>>>>>>>>>>>> Fetch standards >>>>>>>>>>>>>>>> I linked, it is unusable for such obvious cause. Without Push, >>>>>>>>>>>>>>>> we grow >>>>>>>>>>>>>>>> complex systems like grpc-web, which are partial, incomplete, >>>>>>>>>>>>>>>> radically >>>>>>>>>>>>>>>> complex alternatives to what the browser ought just be able to >>>>>>>>>>>>>>>> do, what >>>>>>>>>>>>>>>> only the most minor, long requested additions to Push would >>>>>>>>>>>>>>>> have allowed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And now here we are, building Early Hints to try to reclaim >>>>>>>>>>>>>>>> only the most minor, smallest of advantages Push gave us. >>>>>>>>>>>>>>>> Focused only on >>>>>>>>>>>>>>>> this one tiny bit of the puzzle. And told that we must DIY >>>>>>>>>>>>>>>> alternatives if >>>>>>>>>>>>>>>> we want them, using WebTransport, and told that this web >>>>>>>>>>>>>>>> browser will not >>>>>>>>>>>>>>>> support the one optional component of the HTTP standard. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Words have not had an effect on me. This decision continues >>>>>>>>>>>>>>>> to have a profound & disturbing effect on me, and it should be >>>>>>>>>>>>>>>> reversed. >>>>>>>>>>>>>>>> Hopefully before we need to start implementing HTTP3 over >>>>>>>>>>>>>>>> WebTransport, but >>>>>>>>>>>>>>>> I rather suspect not. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- > 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/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com.
