Howdy Chris, et al, Early Hints launched to Stable in M103. As such we would like to revive this Intent to Remove HTTP/2 Server Push.
Cheers, Ryan On Wed, Mar 2, 2022 at 9:51 AM Chris Harrelson <chris...@chromium.org> wrote: > The API owners met today and discussed this intent at some length. > > We are very happy that Early Hints is showing very positive promise in > terms of experimental data, and feel the positive experimental data is > enough to justify starting the process to remove HTTP/2 push. > > To that end, we approve starting official deprecation of the feature now, > with a (publicly communicated) goal to remove support from Chromium in the > next 6-9 months. We recommend publishing a blog post describing what's > happening and the recommended migration paths. > > However, we would like to see an Early Hints intent-to-ship before > approving actual removal of HTTP/2 Push; please do not consider this an > email an approval to actually remove it until we send LGTMs for such. Our > understanding is that Early Hints is well on the way to a finished spec and > readiness to ship, and the remaining pieces of the specification are to > nail down integration with other related APIs such as Fetch. We think this > sounds feasible to complete and reach a shipped-in-stable-channel status > within the proposed deprecation period, which would allow sites to > potentially have a seamless transition. > > We recognize that this is a long time period, and especially long given > the time since the start of the request to deprecate. The reason is that > we'd really like to avoid the "old thing is deprecated, new thing is not > yet available" situation if possible. Thank you everyone for your patience > and efforts. > > Regards, > Chris > > > On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <denom...@chromium.org> > wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com?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/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com?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/CAJ_4DfSJ7kapqg0-S-WQfTBcuLBrVuazwswo6gwoFWV3m4jk%3DA%40mail.gmail.com.
