fetch

Note that caching resources across sites isn't really a thing anymore. See https://github.com/whatwg/fetch/issues/904

Maybe referring to GET, not POST/PUT bodies? https://github.com/whatwg/fetch/issues/83 Seems pretty short-sighted of a decision there, since XMLHTTPReq does it just fine, and it is in the HTTP RFC's

As I commented yesterday[1], accelerating page loading was only one use case for http Push frames. Alas it's the only ude case Chrome ever acknowledged or cared about or have ever seemingly recognized (in spite of it under-the-hood powering Push API). Push also could have been useful to replace theess of non-web non-resourceful ad-hoc protocols people have endlessly kept reinventing atop WebSockets/WebTransport/SSE/Long-polling to push things like new chat messages to the browser. The author cites Jake Archibald's struggle using Push for page loading. But Jake also was interested in expanding past this incredibly limited use case, and threw together a mini-proposal to let Fetch hear of incoming Pushed resources[2]. Chrome though largely have never acknowledged this desire, even though it's been asked for for ~7 years now. So the web is st

As usual from Chrome, 100% ignores the fact that developers have wanted to use fetch to be able to reactively hear of resources coming in, & chrome has (largely) ignored these pleas. The post focuses only around the most boring & basic capability of webpage loading, since that was the only capability developers ever got. The article talks about Jake Archibald enumerating some problems with PUSH. Well, Jake was also author to a mini-proposal to add Push support to fetch so developers could try out other uses for push. Seemingly ignored by chrome. https://github.com/whatwg/fetch/issues/607 Having the browser be a minimalist, picky implementation of http protocols is hard for me to reconcile & be ok with. There's well over a half decade of neglect & plugging their ears on Chrome's side around Push, not listening to users, not delivering us l

Sure, that's fair enough. But I'm not sure if characterizing this feature as a pet feature of the gRPC team is accurate either - after all, it's simply exposing an HTTP 1.1 & H2 feature, and it was already in the WHATWG fetch spec. There, the security concerns were apparently discussed as well [1], and adding the trailer headers as a separate object was deemed safe. I haven't read the entire discussion and don't have a vested interest in it, but the WHATWG spec seems like a better place to have this discussion, and come to a conclusion, than the Chromium issue tracker. Apparently, there is a new issue for it, so that might yet happen: [2]. [1]: https://github.com/whatwg/fetch/issues/34 [2]: https://github.com/whatwg/fetch/issues/981

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial effect. The Area Tech Leads of Cloud also failed to convince their peers in Chrome, and as a result, trailers were ripped out [from the WHATWG fetch specification]. FWIW, I personally think it's a good thing that other teams within Google don't have too much of an "advantage" for getting features into Chrome, compared to other web developers, however, I also think it's very unfortunate that a single Chrome engineer gets to decide not only that it shouldn't be implemented in Chromium, but that that also has the effect of it being removed from the specification. (The linked issue [1] was also opened by a Google employee.) Of course, you might reasonably argue that, without consensus a

From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If browser makers are slow to expose new protocol features, that's a cost I'm happy to pay. At least as I understand it, HTTP Push isn't the problem. The key problem is that browsers don't want to expose HTTP trailers. I understand their reluctance - even putting aside the security concerns, it's a huge semantic change. Many HTTP response headers, like etags, are typically computed by buffering the response, running some compute, then sending headers and the buffered body. All of those would, presumably, now need to also be sendable as trailers. What if the server sends both an etag header and trailer, and they don't m

If the browser folk had ever made HTTP Push available for use to the web page, such that actual grpc could run, I'd agree. gRPC/the web are at an impasse versus browsermakers who are resistant to new capabilities & who gave up on push as unsuccessful after never letting us try. Here's a good recent (4 year old) issue; it links back to much older issues. https://github.com/whatwg/fetch/issues/607 The rest of the protobuf world has gotten so much better. But the grpc on the web hacks feel bad. The awful option of running http3-over-webtransport-over-http3 is becoming alluring given the lack of browser care for the basics, and that's terrifying (it means the page loading & running it's own page/userland http3 stack). But there doesn't seem to be room for progress & innovation & even basic continuity/ways forward, with HTTP Push getting shove

I'm mad the browser has gotten not at all better at doing HTTP. It's criminal that Fetch never developed Push support[1], and now the browser is removing it, having never let us even try to use this capability. I think things like multi-way streaming are probably much more doable with modern Fetch, but I'm not totally sure. The browser folks have such a narrowminded view on what http is for. If it can't help them load pages off one of their CDNs faster, they don't care. [1] https://github.com/whatwg/fetch/issues/65

No mention of what browsers do for notifications, Web Push Protocl[1]. Which makes sense only in the context of the one of the ancient grand-daddy issues of Fetch being completely ignored by the powers that be[2], & the browser & the browser alone (not the page) having the capability to hear & observe HTTP2+ PUSH requests coming in. This github issue to let a fetch request hear PUSH responses come back at it has been mostly ignored, for 3/4 a decade. Meanwhile Chrome is saying people don't use Push. Yeah, well, because ye jerknuts have diluted & made unusable the best part of it: the ability to be responsive to resources coming at us. What a sad truckload of tragedy this undelivered capability has been. To invent a new HTTP, HTTP2, with new capabilities, then spend most of a decade ignoring & denying developers access to the best parts of

There's a relevant spec issue here https://github.com/whatwg/fetch/issues/973

There's a relevant spec issue you can follow here https://github.com/whatwg/fetch/issues/973

This is fetch: https://github.com/whatwg/fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API Here is discussion about it in Node with some (pretty old) discussion https://docs.google.com/document/d/1tn_-0S_FG_sla81wFohi8Sc8...