The reason is if your website is fast you don't need to buy CDN and Akamai (and the like) looses money. All this technical reasoning is false. Also fake are the statistics about saying nobody uses push. How could Akamai actually know how much traffic my site does with push? They simply can't. The only thing they can count is the number of their customers. But most stupid is Googles reasoning to disable a working feature in Chrome based on statistics. They had a very strong reason to come up with spdy and push in the first place. Simply leaving the feature as it is would not cost them a dime. But since it does harm to the CDN business the world is not allowed to enjoy fast sites with push. Oh the internet is slow I need a faster computer.... Also saying that because push is optional in http2, turning it off would leave Chrome HTTP/2 standard compliant is like saying a browser is HTTP/2 compliant if it downgrades to http/1.0 and gets the page. Push may be optional to use but it is THE killer feature of http2. Why should one use http2 insted? For header compression or binary - nope. With brotli or gzip there is already binary and why bother for a few headers. But every end is a new beginning. I look forward to the push enabled forks of the browsers. Goodbye Chrome. On Thursday, November 12, 2020 at 6:13:08 AM UTC+1 Samuel Williams wrote:
> As someone who has implemented HTTP/2 push in both the client and server, > I fully support this change and would like to see it deprecated from the > RFCs. The complexity in both the client and the server is non-trivial, and > the benefit has not been proven even in isolation. > > The HTTP request/response model is well understood and lends itself to > relatively sane client and server interfaces. The addition of server push > extends clients and servers in an unnatural way, where a response can can > potentially trigger more responses than the client was interested in. When > you try to write code that handles this, the only abstraction that comes to > mind is a queue: > > response = client.request(path) > response.promises.each do |promise| > add_to_cache(promise) > end > response.body.read # etc > > But this is very unnatural to most users. Not to mention that this also > invites issues around concurrency. > > Browsers (and clients in general) are far better at knowing what resources > they need. My experience has been that HTTP/2 push can only helps users on > the first request. Looking at implementations like h2o, we see the extreme > level of complexity required to try and avoid superfluous pushing. After > the first request, the local browser has cached everything of interest, and > from that point on HTTP/2 push does not serve any purpose as far as I can > tell. > > The level of complexity introduced by this feature does not balance out > with the value it brings. > > To repeat, I fully support this change. > > Kind regards, > Samuel > On Thursday, November 12, 2020 at 3:26:20 PM UTC+13 Ian Swett wrote: > >> Anyone who objects should feel free to share data publicly which supports >> their case, as Akamai did a few years ago. That data was very mixed and >> not particularly compelling on average, and the metrics have degraded since >> then, so I expect the metrics would look worse today. >> >> On Wed, Nov 11, 2020 at 9:22 PM Jay Phelps <j...@outsmartly.com> wrote: >> >>> We disagree with this decision based on the real world data we have seen >>> and the products we build around Http/2 Push. Just making our objection >>> known. >>> >>> -- >>> Jay Phelps >>> Outsmartly >>> >>> On Wednesday, November 11, 2020 at 9:00:52 PM UTC-5 Ian Swett wrote: >>> >>>> To clarify, server push is an optimization in HTTP/2(and presumably >>>> HTTP/3) that is optional and there is no requirement to implement it in >>>> either spec. It does not exist in HTTP/1.1. This is not an indicatoin >>>> Chrome does not support HTTP(S), since clearly Chrome would be useless if >>>> that occurred, but rather about removing an optimization that was not >>>> widely used and when it was used, typically not used wisely. >>>> >>>> I support this change because I think efforts would be better spent >>>> elsewhere(ie: Alt-SVC, DoH, HTTP/3, ESNI, ...) >>>> >>>> Ian >>>> On Wednesday, November 11, 2020 at 8:35:24 PM UTC-5 Morgaine wrote: >>>> >>>>> On Wednesday, November 11, 2020 at 5:00:39 PM UTC-5 >>>>> las...@chromium.org wrote: >>>>> >>>>>> Chrome currently supports handling push streams over HTTP/2 and >>>>>> gQUIC, and this intent is about removing support over both protocols. >>>>>> Chrome does not support push over HTTP/3 and adding support is not on >>>>>> the >>>>>> roadmap. >>>>>> >>>>> >>>>> This is horrifying to hear. Please support the HTTP protocol. Please >>>>> do not remove support, roll back the web, just because we have not >>>>> figured >>>>> out yet the good ways to use an advanced feature. Please have a plan for >>>>> supporting HTTP!!!!!!! This is so scary to hear, and so unacceptable. >>>>> >>>>> This is something that should make the web better. Web sites have been >>>>> slow to figure out how to make this feature effective. But I believe in >>>>> it >>>>> fully. Not shipping HTTP support in Chrome would certainly be the >>>>> death-knell for Push, and such a massive revolutionary change as Push >>>>> deserves to have a decade plus for us to figure out how to use it >>>>> effectively. Don't pull the plug on push like this. Don't. Please, >>>>> please, >>>>> don't. This is so scary to hear. I can not believe I am reading this. >>>>> >>>> -- 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/39b82b83-3e6e-48a5-905d-1cab3651196an%40chromium.org.
