[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Anton Bershanskyi]

Hi Grzegorz,

HTTP/2 server push was disabled by default in Chrome 106[1]. You can 
achieve the almost the same latency speedup via preloading and prerendering 
(rel=preload [2] and rel=prerender) and HTTP Early Hints[3] (supported 
since Chrome 103) and speculation rules.

[1] https://developer.chrome.com/blog/removing-push/
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload
[3] https://developer.chrome.com/blog/early-hints/

Hope that helps.
On Monday, October 16, 2023 at 1:41:53 AM UTC+3 Grzegorz Szeliga wrote:

> Is this function still active? I was just getting around to using it to 
> speed up my site and here I find such threads of concern
>
> czwartek, 27 kwietnia 2023 o 21:14:40 UTC+2 Gerald Witichis napisał(a):
>
>> 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  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 

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Grzegorz Szeliga]

Is this function still active? I was just getting around to using it to 
speed up my site and here I find such threads of concern

czwartek, 27 kwietnia 2023 o 21:14:40 UTC+2 Gerald Witichis napisał(a):

> 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  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 

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Gerald Witichis]

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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

Done: https://bugs.chromium.org/p/chromium/issues/detail?id=1415291


Mitar

On Wed, Nov 2, 2022 at 11:46 PM Mike Taylor  wrote:
>
> Hi Mitar,
>
> This is really good feedback. Would you mind filing a bug at
> crbug.com/new? Feel free to respond here with the link.
>
> thanks,
> Mike
>
> On 11/1/22 11:25 AM, Mitar wrote:
> > Hi!
> >
> > After playing more with link preload header, I have found another
> > issue where it fails flat as a replacement for server push: where
> > response type depends on Accept header (e.g., APIs which can return
> > XML or JSON depending on Accept header, i.e., content negotiation).
> > You cannot really specify what is used as an Accept header with link
> > rel="preload" and as="fetch" and it looks like Chrome always sets
> > Accept: */*, even if you specify type="application/json".
> >
> >
> > Mitar
> >
> > On Sun, Jul 10, 2022 at 8:04 PM Mitar  wrote:
> >> Hi!
> >>
> >> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan  
> >> wrote:
> >>> Presumably if you are protecting something behind HTTP Auth then the PUSH 
> >>> is happening AFTER the 401 challenge and the browser has made the 
> >>> follow-on request with the Authorization header.  If not, then the 
> >>> resources aren't actually protected by authorization and PUSH is 
> >>> bypassing the auth.
> >> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
> >> data from REST API using Authorization header. The server-side can
> >> know that after loading the code, SPA will contact the REST API, so
> >> with HTTP2 you can push the JSON data to the client (setting
> >> Authorization header. as an expected header to be used in the request,
> >> and because it knows the logic of SPA it can also know the value of
> >> the Authorization header). This mitigates the question about whether
> >> you should embed this JSON into HTML response or provide it through
> >> API. Because you can push, there is little difference, but it can be
> >> seen as cleaner to separate HTML payload from data payload.
> >>
> >>> In the early-hints case, the 103 should presumably also be after the 
> >>> request has made it past HTTP Auth so any requests for subresources would 
> >>> use the cached credentials,
> >> That works with cookies, but not with REST API which uses bearer token
> >> in Authorization header. Or am I mistaken?
> >>
> >>> Content negotiation works fine for "as" types that have "accept" types 
> >>> associated with them.
> >> There are some issues opened for Chromium around that [1] [2], but
> >> maybe that is just implementation bug?
> >>
> >>> The PUSH case doesn't support custom authorization or content negotiation 
> >>> either.
> >> You can provide Authorization header in request headers in PUSH_PROMISE 
> >> frame?
> >>
> >>> PUSH is going to go away, the only real question is how long it will 
> >>> take, not if enough edge cases are found to keep it.
> >> I think I understand that. But I am trying to understand what are
> >> alternatives for the edge cases I care about. Initially it looked like
> >> Early Hints is the proposed alternative, but it looks like it does not
> >> support all use cases.
> >>
> >> Currently to me it looks like the best bet is to move the bearer token
> >> to Cookie header. That one might be included when doing a preload
> >> through Link header.
> >>
> >> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
> >> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
> >>
> >>
> >> Mitar
> >>
> >> --
> >> http://mitar.tnode.com/
> >> https://twitter.com/mitar_m
> >
> >
>


-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikP19rmngMvjxC-n4cGrSYbMShXdvTYJzTT0Mi019pJwdg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Yoav Weiss]

There's a relevant issue filed on the HTML spec:
https://github.com/whatwg/html/issues/7887


On Wed, Nov 2, 2022 at 11:46 PM Mike Taylor  wrote:

> Hi Mitar,
>
> This is really good feedback. Would you mind filing a bug at
> crbug.com/new? Feel free to respond here with the link.
>
> thanks,
> Mike
>
> On 11/1/22 11:25 AM, Mitar wrote:
> > Hi!
> >
> > After playing more with link preload header, I have found another
> > issue where it fails flat as a replacement for server push: where
> > response type depends on Accept header (e.g., APIs which can return
> > XML or JSON depending on Accept header, i.e., content negotiation).
> > You cannot really specify what is used as an Accept header with link
> > rel="preload" and as="fetch" and it looks like Chrome always sets
> > Accept: */*, even if you specify type="application/json".
> >
> >
> > Mitar
> >
> > On Sun, Jul 10, 2022 at 8:04 PM Mitar  wrote:
> >> Hi!
> >>
> >> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan 
> wrote:
> >>> Presumably if you are protecting something behind HTTP Auth then the
> PUSH is happening AFTER the 401 challenge and the browser has made the
> follow-on request with the Authorization header.  If not, then the
> resources aren't actually protected by authorization and PUSH is bypassing
> the auth.
> >> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
> >> data from REST API using Authorization header. The server-side can
> >> know that after loading the code, SPA will contact the REST API, so
> >> with HTTP2 you can push the JSON data to the client (setting
> >> Authorization header. as an expected header to be used in the request,
> >> and because it knows the logic of SPA it can also know the value of
> >> the Authorization header). This mitigates the question about whether
> >> you should embed this JSON into HTML response or provide it through
> >> API. Because you can push, there is little difference, but it can be
> >> seen as cleaner to separate HTML payload from data payload.
> >>
> >>> In the early-hints case, the 103 should presumably also be after the
> request has made it past HTTP Auth so any requests for subresources would
> use the cached credentials,
> >> That works with cookies, but not with REST API which uses bearer token
> >> in Authorization header. Or am I mistaken?
> >>
> >>> Content negotiation works fine for "as" types that have "accept" types
> associated with them.
> >> There are some issues opened for Chromium around that [1] [2], but
> >> maybe that is just implementation bug?
> >>
> >>> The PUSH case doesn't support custom authorization or content
> negotiation either.
> >> You can provide Authorization header in request headers in PUSH_PROMISE
> frame?
> >>
> >>> PUSH is going to go away, the only real question is how long it will
> take, not if enough edge cases are found to keep it.
> >> I think I understand that. But I am trying to understand what are
> >> alternatives for the edge cases I care about. Initially it looked like
> >> Early Hints is the proposed alternative, but it looks like it does not
> >> support all use cases.
> >>
> >> Currently to me it looks like the best bet is to move the bearer token
> >> to Cookie header. That one might be included when doing a preload
> >> through Link header.
> >>
> >> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
> >> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
> >>
> >>
> >> Mitar
> >>
> >> --
> >> http://mitar.tnode.com/
> >> https://twitter.com/mitar_m
> >
> >
>
> --
> 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/2bb46e42-a270-78a2-a473-e37739058d98%40chromium.org
> .
>

-- 
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/CAL5BFfU1p4mPB8%2ButM8bt6rSgGQTiMymh7rVaaQqmyb11jbgGA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mike Taylor]

Hi Mitar,

This is really good feedback. Would you mind filing a bug at 
crbug.com/new? Feel free to respond here with the link.


thanks,
Mike

On 11/1/22 11:25 AM, Mitar wrote:

Hi!

After playing more with link preload header, I have found another
issue where it fails flat as a replacement for server push: where
response type depends on Accept header (e.g., APIs which can return
XML or JSON depending on Accept header, i.e., content negotiation).
You cannot really specify what is used as an Accept header with link
rel="preload" and as="fetch" and it looks like Chrome always sets
Accept: */*, even if you specify type="application/json".


Mitar

On Sun, Jul 10, 2022 at 8:04 PM Mitar  wrote:

Hi!

On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan  wrote:

Presumably if you are protecting something behind HTTP Auth then the PUSH is 
happening AFTER the 401 challenge and the browser has made the follow-on 
request with the Authorization header.  If not, then the resources aren't 
actually protected by authorization and PUSH is bypassing the auth.

I am not talking about HTTP Auth, but a simple SPA which fetches JSON
data from REST API using Authorization header. The server-side can
know that after loading the code, SPA will contact the REST API, so
with HTTP2 you can push the JSON data to the client (setting
Authorization header. as an expected header to be used in the request,
and because it knows the logic of SPA it can also know the value of
the Authorization header). This mitigates the question about whether
you should embed this JSON into HTML response or provide it through
API. Because you can push, there is little difference, but it can be
seen as cleaner to separate HTML payload from data payload.


In the early-hints case, the 103 should presumably also be after the request 
has made it past HTTP Auth so any requests for subresources would use the 
cached credentials,

That works with cookies, but not with REST API which uses bearer token
in Authorization header. Or am I mistaken?


Content negotiation works fine for "as" types that have "accept" types 
associated with them.

There are some issues opened for Chromium around that [1] [2], but
maybe that is just implementation bug?


The PUSH case doesn't support custom authorization or content negotiation 
either.

You can provide Authorization header in request headers in PUSH_PROMISE frame?


PUSH is going to go away, the only real question is how long it will take, not 
if enough edge cases are found to keep it.

I think I understand that. But I am trying to understand what are
alternatives for the edge cases I care about. Initially it looked like
Early Hints is the proposed alternative, but it looks like it does not
support all use cases.

Currently to me it looks like the best bet is to move the bearer token
to Cookie header. That one might be included when doing a preload
through Link header.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m





--
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/2bb46e42-a270-78a2-a473-e37739058d98%40chromium.org.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

After playing more with link preload header, I have found another
issue where it fails flat as a replacement for server push: where
response type depends on Accept header (e.g., APIs which can return
XML or JSON depending on Accept header, i.e., content negotiation).
You cannot really specify what is used as an Accept header with link
rel="preload" and as="fetch" and it looks like Chrome always sets
Accept: */*, even if you specify type="application/json".


Mitar

On Sun, Jul 10, 2022 at 8:04 PM Mitar  wrote:
>
> Hi!
>
> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan  wrote:
> > Presumably if you are protecting something behind HTTP Auth then the PUSH 
> > is happening AFTER the 401 challenge and the browser has made the follow-on 
> > request with the Authorization header.  If not, then the resources aren't 
> > actually protected by authorization and PUSH is bypassing the auth.
>
> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
> data from REST API using Authorization header. The server-side can
> know that after loading the code, SPA will contact the REST API, so
> with HTTP2 you can push the JSON data to the client (setting
> Authorization header. as an expected header to be used in the request,
> and because it knows the logic of SPA it can also know the value of
> the Authorization header). This mitigates the question about whether
> you should embed this JSON into HTML response or provide it through
> API. Because you can push, there is little difference, but it can be
> seen as cleaner to separate HTML payload from data payload.
>
> > In the early-hints case, the 103 should presumably also be after the 
> > request has made it past HTTP Auth so any requests for subresources would 
> > use the cached credentials,
>
> That works with cookies, but not with REST API which uses bearer token
> in Authorization header. Or am I mistaken?
>
> > Content negotiation works fine for "as" types that have "accept" types 
> > associated with them.
>
> There are some issues opened for Chromium around that [1] [2], but
> maybe that is just implementation bug?
>
> > The PUSH case doesn't support custom authorization or content negotiation 
> > either.
>
> You can provide Authorization header in request headers in PUSH_PROMISE frame?
>
> > PUSH is going to go away, the only real question is how long it will take, 
> > not if enough edge cases are found to keep it.
>
> I think I understand that. But I am trying to understand what are
> alternatives for the edge cases I care about. Initially it looked like
> Early Hints is the proposed alternative, but it looks like it does not
> support all use cases.
>
> Currently to me it looks like the best bet is to move the bearer token
> to Cookie header. That one might be included when doing a preload
> through Link header.
>
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikN%2Buz3hv44Sy0E8%3DyPAzkzkmPYtmiLjpSAEWSNp%3D2yg8g%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Chris Harrelson]

LGTM2 to remove with the condition that there be a public blog post
specific to it that outlines (briefly is ok) what is happening, why, and
recommended alternatives for developers.

Thanks! I appreciate the diligence and patience of the team, I recognize
this has been a long process.

On Wed, Aug 17, 2022 at 8:41 AM Alex Russell 
wrote:

> Per today's OWNERS meeting, LGTM1
>
> On Tuesday, August 16, 2022 at 10:41:57 AM UTC-7 jme...@google.com wrote:
>
>> So it will be disabled by default in 106 then?
>>
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 15, 2022 at 8:13 AM Brad Lassey  wrote:
>>
>>> I believe Ian's timeline suggestion was to disable on trunk this week
>>> and let it ride to stable in m106.
>>>
>>> -Brad
>>>
>>>
>>> On Mon, Aug 15, 2022 at 10:39 AM Joe Medley  wrote:
>>>
 Ryan,

 What's the planned schedule for deprecation and removal?
 Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195 <(816)%20678-7195>
 *If an API's not documented it doesn't exist.*


 On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:

> 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 
> 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 
>> wrote:
>>
>>> Hello,
>>>
>>> We conducted an experiment for Early Hints (chromestatus
>>> ) 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
>>>  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  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  wrote:
>>>
 I'm not sure if you are being deliberately cruel & 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Alex Russell]

Per today's OWNERS meeting, LGTM1

On Tuesday, August 16, 2022 at 10:41:57 AM UTC-7 jme...@google.com wrote:

> So it will be disabled by default in 106 then?
>
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 15, 2022 at 8:13 AM Brad Lassey  wrote:
>
>> I believe Ian's timeline suggestion was to disable on trunk this week and 
>> let it ride to stable in m106.
>>
>> -Brad
>>
>>
>> On Mon, Aug 15, 2022 at 10:39 AM Joe Medley  wrote:
>>
>>> Ryan,
>>>
>>> What's the planned schedule for deprecation and removal?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | 
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>>>
 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  
 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  
> wrote:
>
>> Hello,
>>
>> We conducted an experiment for Early Hints (chromestatus 
>> ) 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 
>>  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  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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

['Joe Medley' via blink-dev]

So it will be disabled by default in 106 then?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 15, 2022 at 8:13 AM Brad Lassey  wrote:

> I believe Ian's timeline suggestion was to disable on trunk this week and
> let it ride to stable in m106.
>
> -Brad
>
>
> On Mon, Aug 15, 2022 at 10:39 AM Joe Medley  wrote:
>
>> Ryan,
>>
>> What's the planned schedule for deprecation and removal?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>>
>>> 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 
>>> 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 
 wrote:

> Hello,
>
> We conducted an experiment for Early Hints (chromestatus
> ) 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
>  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  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  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, 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Brad Lassey]

I believe Ian's timeline suggestion was to disable on trunk this week and
let it ride to stable in m106.

-Brad


On Mon, Aug 15, 2022 at 10:39 AM Joe Medley  wrote:

> Ryan,
>
> What's the planned schedule for deprecation and removal?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>
>> 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 
>> 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 
>>> wrote:
>>>
 Hello,

 We conducted an experiment for Early Hints (chromestatus
 ) 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
  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  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  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.
>

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

['Joe Medley' via blink-dev]

Ryan,

What's the planned schedule for deprecation and removal?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:

> 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 
> 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 
>> wrote:
>>
>>> Hello,
>>>
>>> We conducted an experiment for Early Hints (chromestatus
>>> ) 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
>>>  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  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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

['Ian Swett' via blink-dev]

Are you referring to "We  recommend publishing a blog post describing
what's happening and the recommended migration paths."?

That server push is deprecated was mentioned in the early hints blog post:
https://developer.chrome.com/blog/early-hints/#relationship-to-h2push



On Fri, Aug 12, 2022 at 8:38 AM Yoav Weiss  wrote:

> Hey Ian! :) Did the public communication that Chris asked for
> 
> happened?
>
> On Thu, Aug 11, 2022 at 9:15 PM 'Ian Swett' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> An increasing fraction of Chrome traffic is now HTTP/3 (which has
>> always had server push disabled), so disabling it for HTTP/2 should be a
>> fairly low impact change.
>>
>> I'd like to do it in Chrome Canary this week and let it move to Stable,
>> given we've reached all the previously agreed upon milestones.
>>
>> Ian
>>
>> On Tue, Aug 9, 2022 at 10:10 AM Joe Medley  wrote:
>>
>>> What's the intended milestone for this?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>>>
 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 
 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 
> wrote:
>
>> Hello,
>>
>> We conducted an experiment for Early Hints (chromestatus
>> ) 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
>>  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  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  wrote:
>>
>>> I'm not sure if you are being deliberately cruel & malicious, or
>>> just accidentally cruel. Web developers have been begging for Fetch to

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Yoav Weiss]

Hey Ian! :) Did the public communication that Chris asked for

happened?

On Thu, Aug 11, 2022 at 9:15 PM 'Ian Swett' via blink-dev <
blink-dev@chromium.org> wrote:

> An increasing fraction of Chrome traffic is now HTTP/3 (which has
> always had server push disabled), so disabling it for HTTP/2 should be a
> fairly low impact change.
>
> I'd like to do it in Chrome Canary this week and let it move to Stable,
> given we've reached all the previously agreed upon milestones.
>
> Ian
>
> On Tue, Aug 9, 2022 at 10:10 AM Joe Medley  wrote:
>
>> What's the intended milestone for this?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>>
>>> 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 
>>> 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 
 wrote:

> Hello,
>
> We conducted an experiment for Early Hints (chromestatus
> ) 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
>  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  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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

['Ian Swett' via blink-dev]

An increasing fraction of Chrome traffic is now HTTP/3 (which has
always had server push disabled), so disabling it for HTTP/2 should be a
fairly low impact change.

I'd like to do it in Chrome Canary this week and let it move to Stable,
given we've reached all the previously agreed upon milestones.

Ian

On Tue, Aug 9, 2022 at 10:10 AM Joe Medley  wrote:

> What's the intended milestone for this?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:
>
>> 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 
>> 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 
>>> wrote:
>>>
 Hello,

 We conducted an experiment for Early Hints (chromestatus
 ) 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
  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  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  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
> 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

['Joe Medley' via blink-dev]

What's the intended milestone for this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 8, 2022 at 2:46 PM Ryan Hamilton  wrote:

> 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 
> 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 
>> wrote:
>>
>>> Hello,
>>>
>>> We conducted an experiment for Early Hints (chromestatus
>>> ) 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
>>>  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  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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Yoav Weiss]

Thanks Ryan for pushing this through (pun not intended..)

What timeline did y'all have in mind for deprecation and removal? Any
progress on the public communication front discussed earlier

?

Cheers :)
Yoav

On Mon, Aug 8, 2022 at 11:46 PM Ryan Hamilton  wrote:

> 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 
> 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 
>> wrote:
>>
>>> Hello,
>>>
>>> We conducted an experiment for Early Hints (chromestatus
>>> ) 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
>>>  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  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  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

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Ryan Hamilton]

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 
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 
> wrote:
>
>> Hello,
>>
>> We conducted an experiment for Early Hints (chromestatus
>> ) 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
>>  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  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  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

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Yoav Weiss]

FWIW, there's an independent feature request to enable preloading with
arbitrary headers .

On Sun, Jul 10, 2022 at 11:47 PM Patrick Meenan 
wrote:

> I don't think there's a good way to pre-cache something with VARY headers
> (which presumably the push promise includes to make sure the auth header
> matches expectations) to fulfill a future API call.
>
> If you control the app code and can make it check other places for the API
> data then something like edge-side includes (or workers) where the API data
> is injected at the end of the HTML stream could work across all browsers
> and protocols or web bundles could bundle the API data with the response in
> a more disaggregated way (but still experimental and Chrome-specific).
>
> You could preload with nonce query params on the URL instead of a specific
> header but if you're trying to accelerate a black-box app that won't help.
> You could also use a service worker to rewrite the API call to match
> something else injected into cache but that won't help with the first load.
>
> On Sun, Jul 10, 2022 at 2:05 PM Mitar  wrote:
>
>> Hi!
>>
>> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan 
>> wrote:
>> > Presumably if you are protecting something behind HTTP Auth then the
>> PUSH is happening AFTER the 401 challenge and the browser has made the
>> follow-on request with the Authorization header.  If not, then the
>> resources aren't actually protected by authorization and PUSH is bypassing
>> the auth.
>>
>> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
>> data from REST API using Authorization header. The server-side can
>> know that after loading the code, SPA will contact the REST API, so
>> with HTTP2 you can push the JSON data to the client (setting
>> Authorization header. as an expected header to be used in the request,
>> and because it knows the logic of SPA it can also know the value of
>> the Authorization header). This mitigates the question about whether
>> you should embed this JSON into HTML response or provide it through
>> API. Because you can push, there is little difference, but it can be
>> seen as cleaner to separate HTML payload from data payload.
>>
>> > In the early-hints case, the 103 should presumably also be after the
>> request has made it past HTTP Auth so any requests for subresources would
>> use the cached credentials,
>>
>> That works with cookies, but not with REST API which uses bearer token
>> in Authorization header. Or am I mistaken?
>>
>> > Content negotiation works fine for "as" types that have "accept" types
>> associated with them.
>>
>> There are some issues opened for Chromium around that [1] [2], but
>> maybe that is just implementation bug?
>>
>> > The PUSH case doesn't support custom authorization or content
>> negotiation either.
>>
>> You can provide Authorization header in request headers in PUSH_PROMISE
>> frame?
>>
>> > PUSH is going to go away, the only real question is how long it will
>> take, not if enough edge cases are found to keep it.
>>
>> I think I understand that. But I am trying to understand what are
>> alternatives for the edge cases I care about. Initially it looked like
>> Early Hints is the proposed alternative, but it looks like it does not
>> support all use cases.
>>
>> Currently to me it looks like the best bet is to move the bearer token
>> to Cookie header. That one might be included when doing a preload
>> through Link header.
>>
>> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
>> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
>>
>>
>> Mitar
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
> --
> 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/CAPq58w7y_FUBmmzY2k1jSrqS%2BYSELDpBhTUR2anNLXwGw6TaRQ%40mail.gmail.com
> 
> .
>

-- 
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/CAL5BFfU80ahqMDgXbkJ95gL2zyYnC11ZgJOBTvofM26BFng2HQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Patrick Meenan]

I don't think there's a good way to pre-cache something with VARY headers
(which presumably the push promise includes to make sure the auth header
matches expectations) to fulfill a future API call.

If you control the app code and can make it check other places for the API
data then something like edge-side includes (or workers) where the API data
is injected at the end of the HTML stream could work across all browsers
and protocols or web bundles could bundle the API data with the response in
a more disaggregated way (but still experimental and Chrome-specific).

You could preload with nonce query params on the URL instead of a specific
header but if you're trying to accelerate a black-box app that won't help.
You could also use a service worker to rewrite the API call to match
something else injected into cache but that won't help with the first load.

On Sun, Jul 10, 2022 at 2:05 PM Mitar  wrote:

> Hi!
>
> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan 
> wrote:
> > Presumably if you are protecting something behind HTTP Auth then the
> PUSH is happening AFTER the 401 challenge and the browser has made the
> follow-on request with the Authorization header.  If not, then the
> resources aren't actually protected by authorization and PUSH is bypassing
> the auth.
>
> I am not talking about HTTP Auth, but a simple SPA which fetches JSON
> data from REST API using Authorization header. The server-side can
> know that after loading the code, SPA will contact the REST API, so
> with HTTP2 you can push the JSON data to the client (setting
> Authorization header. as an expected header to be used in the request,
> and because it knows the logic of SPA it can also know the value of
> the Authorization header). This mitigates the question about whether
> you should embed this JSON into HTML response or provide it through
> API. Because you can push, there is little difference, but it can be
> seen as cleaner to separate HTML payload from data payload.
>
> > In the early-hints case, the 103 should presumably also be after the
> request has made it past HTTP Auth so any requests for subresources would
> use the cached credentials,
>
> That works with cookies, but not with REST API which uses bearer token
> in Authorization header. Or am I mistaken?
>
> > Content negotiation works fine for "as" types that have "accept" types
> associated with them.
>
> There are some issues opened for Chromium around that [1] [2], but
> maybe that is just implementation bug?
>
> > The PUSH case doesn't support custom authorization or content
> negotiation either.
>
> You can provide Authorization header in request headers in PUSH_PROMISE
> frame?
>
> > PUSH is going to go away, the only real question is how long it will
> take, not if enough edge cases are found to keep it.
>
> I think I understand that. But I am trying to understand what are
> alternatives for the edge cases I care about. Initially it looked like
> Early Hints is the proposed alternative, but it looks like it does not
> support all use cases.
>
> Currently to me it looks like the best bet is to move the bearer token
> to Cookie header. That one might be included when doing a preload
> through Link header.
>
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
> [2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>

-- 
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/CAPq58w7y_FUBmmzY2k1jSrqS%2BYSELDpBhTUR2anNLXwGw6TaRQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan  wrote:
> Presumably if you are protecting something behind HTTP Auth then the PUSH is 
> happening AFTER the 401 challenge and the browser has made the follow-on 
> request with the Authorization header.  If not, then the resources aren't 
> actually protected by authorization and PUSH is bypassing the auth.

I am not talking about HTTP Auth, but a simple SPA which fetches JSON
data from REST API using Authorization header. The server-side can
know that after loading the code, SPA will contact the REST API, so
with HTTP2 you can push the JSON data to the client (setting
Authorization header. as an expected header to be used in the request,
and because it knows the logic of SPA it can also know the value of
the Authorization header). This mitigates the question about whether
you should embed this JSON into HTML response or provide it through
API. Because you can push, there is little difference, but it can be
seen as cleaner to separate HTML payload from data payload.

> In the early-hints case, the 103 should presumably also be after the request 
> has made it past HTTP Auth so any requests for subresources would use the 
> cached credentials,

That works with cookies, but not with REST API which uses bearer token
in Authorization header. Or am I mistaken?

> Content negotiation works fine for "as" types that have "accept" types 
> associated with them.

There are some issues opened for Chromium around that [1] [2], but
maybe that is just implementation bug?

> The PUSH case doesn't support custom authorization or content negotiation 
> either.

You can provide Authorization header in request headers in PUSH_PROMISE frame?

> PUSH is going to go away, the only real question is how long it will take, 
> not if enough edge cases are found to keep it.

I think I understand that. But I am trying to understand what are
alternatives for the edge cases I care about. Initially it looked like
Early Hints is the proposed alternative, but it looks like it does not
support all use cases.

Currently to me it looks like the best bet is to move the bearer token
to Cookie header. That one might be included when doing a preload
through Link header.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1072144


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikNd%3DpMSYN1XXA_Zed0%3DBUzmOcuMm1BqruaMS7D6ap7m1w%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Patrick Meenan]

Presumably if you are protecting something behind HTTP Auth then the PUSH
is happening AFTER the 401 challenge and the browser has made the follow-on
request with the Authorization header.  If not, then the resources aren't
actually protected by authorization and PUSH is bypassing the auth.

In the early-hints case, the 103 should presumably also be after the
request has made it past HTTP Auth so any requests for subresources would
use the cached credentials, just like if they were being fetched as part of
the page. I don't know off the top of my head if GET <- 401 -> GET <- 103
<- 200 works in the current implementation but I could easily see. the case
for filing an issue and making sure it does if it doesn't.

Authorization is not a response header and preload has no way of specifying
arbitrary headers. Content negotiation works fine for "as" types that have
"accept" types associated with them.  It sounds like the concern there is
around being able to specify arbitrary headers and overrides for "fetch"
preloads specifically and that isn't supported by preload in any case
(header or in markup). The PUSH case doesn't support custom authorization
or content negotiation either.

PUSH is going to go away, the only real question is how long it will take,
not if enough edge cases are found to keep it.  HTTP/3 already has no
equivalent (and neither does HTTP/1) and once all of the CDN's move from
automatically creating PUSH frames from preload headers (likely replaced
with using early hints and preload), usage on the web will be a rounding
error away from zero.  A much better approach would be to work with the
loading team if you have a use case that is slow with how the web works
today to see if there are solutions in the pipeline (or that can be
generalized) that solve the issue more cleanly.  For example, if you really
want to serve subresources along with the main content, web bundles
 is an application-level way that is being
worked on to handle that case.

On Sun, Jul 10, 2022 at 7:40 AM Mitar  wrote:

> Hi!
>
> On Mon, Apr 25, 2022 at 9:09 AM Kenji Baheux 
> wrote:
>
>> The Authorization header should be supported in Early Hints.
>> Please share a concrete example if this doesn't work as you'd hope.
>>
>
> Kenji, I think there is some misunderstanding here between what I am
> concerned about (what is possible with HTTP2 push and not with Early Hints).
>
> So with Early Hints Authorization header is supported in the following way:
>
> HTTP/1.1 103 Early Hints
> Link: /api/data.json; rel=preload; as=fetch
> Authorization: Bearer foobar
>
> But this does not mean that the browser will use that header when doing a
> request to preload the /api/data.json. So preloading resources which
> require authorization is not possible with Early Hints. But it is possible
> with HTTP2 push.
>
> Similar and related issue is with Accept header and content negotiation.
> It is not possible to define a Link header which would for example request
> application/json response, when multiple responses are possible. This has
> been reported independently at [1].
>
> So to me it looks like Early Hints support only simple public requests, no
> authorization, no content negotiation. As such they are not suitable to
> preload data from API endpoints. While HTTP2 push can support such use
> cases.
>
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642
>
> Am I missing something obvious about the Link header which would address
> those concerns?
>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>

-- 
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/CAPq58w5d0QGh7Z2Y_ejpeUm%3DwqC9CCnydP%2B9vn9hMVqB0zzJRw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

On Mon, Apr 25, 2022 at 9:09 AM Kenji Baheux 
wrote:

> The Authorization header should be supported in Early Hints.
> Please share a concrete example if this doesn't work as you'd hope.
>

Kenji, I think there is some misunderstanding here between what I am
concerned about (what is possible with HTTP2 push and not with Early Hints).

So with Early Hints Authorization header is supported in the following way:

HTTP/1.1 103 Early Hints
Link: /api/data.json; rel=preload; as=fetch
Authorization: Bearer foobar

But this does not mean that the browser will use that header when doing a
request to preload the /api/data.json. So preloading resources which
require authorization is not possible with Early Hints. But it is possible
with HTTP2 push.

Similar and related issue is with Accept header and content negotiation. It
is not possible to define a Link header which would for example request
application/json response, when multiple responses are possible. This has
been reported independently at [1].

So to me it looks like Early Hints support only simple public requests, no
authorization, no content negotiation. As such they are not suitable to
preload data from API endpoints. While HTTP2 push can support such use
cases.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642

Am I missing something obvious about the Link header which would address
those concerns?


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikN3SaqDDXgQrS%2B8mqk717FnvMfudjtYn7%3DKLq3Snt777w%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[mup co.il.]

   response. Typically, the hints are about critical sub-resources or 
>>>>> origins 
>>>>>which would be used by the final response.
>>>>>3. The browser processes these hints, and decides to preconnect or 
>>>>>preload any missing origins/resources while waiting for the final 200 
>>>>> OK 
>>>>>response (usually containing the main resource). Since the browser got 
>>>>> some 
>>>>>work done ahead of time, the overall page load time is improved.
>>>>>
>>>>> In other words, the key point here is that Early Hints doesn't start 
>>>>> during the HTML parsing: it starts with the non-final response headers, 
>>>>> way 
>>>>> before HTML parsing kicks in since that is blocked on the final response.
>>>>>
>>>>> See this section of the RFC 
>>>>> <https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.>
>>>>>  
>>>>> for an example of how this looks at the HTTP level.
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>> Regarding the complexity to put it in place early hints is easy when 
>>>>>> you serve different page but for Single Page Application the build 
>>>>>> process 
>>>>>> don't generate differentiate serving based on the route since the 
>>>>>> routing 
>>>>>> of the application is generally managed in the frontend.
>>>>>> So for Single Page Application to managed server push not global to 
>>>>>> all route it will more complexe to include it in the build process.
>>>>>>
>>>>>
>>>>> The MPA angle is indeed easier, deployment wise.
>>>>> We'll look into the SPA case in more details including discussion with 
>>>>> various framework authors.
>>>>>
>>>>> I hope this was useful.
>>>>>  
>>>>>
>>>>>>
>>>>>> Just wanted to share my feeling about this whole topic.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>  
>>>>>>
>>>>>> *Thomas BIANCONI*
>>>>>>
>>>>>> Head of Data Technologies
>>>>>>
>>>>>> & Data Privacy Champion
>>>>>>
>>>>>> Global CDMO Team
>>>>>>
>>>>>> 41 Rue Martre - 92110 Clichy
>>>>>>
>>>>>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>>>>>>
>>>>>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>>>>>>
>>>>>> *E-mail* : thomas@loreal.com
>>>>>>
>>>>>> --
>>>>>> *De :* Chris Harrelson 
>>>>>> *Envoyé :* mercredi 2 mars 2022 18:51
>>>>>> *À :* Daisuke Enomoto 
>>>>>> *Cc :* blink-dev ; las...@chromium.org <
>>>>>> las...@chromium.org>; pme...@chromium.org ; 
>>>>>> Francesco Montanari ; Maxim Makarov <
>>>>>> maxpa...@gmail.com>; b...@chromium.org ; 
>>>>>> dsch...@chromium.org ; ians...@chromium.org <
>>>>>> ians...@chromium.org>; rektide ; Ben Lesh <
>>>>>> b...@benlesh.com>; Andrew Wilder ; Vito De 
>>>>>> Giosa 
>>>>>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC 
>>>>>> server push 
>>>>>>  
>>>>>> Notice: External mail 
>>>>>> 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 (p

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Carlos Lopez]

nvolves%20a%20103%20(Early%20Hints)%20response.>
>>>>  
>>>> for an example of how this looks at the HTTP level.
>>>>
>>>>
>>>>  
>>>>
>>>>> Regarding the complexity to put it in place early hints is easy when 
>>>>> you serve different page but for Single Page Application the build 
>>>>> process 
>>>>> don't generate differentiate serving based on the route since the routing 
>>>>> of the application is generally managed in the frontend.
>>>>> So for Single Page Application to managed server push not global to 
>>>>> all route it will more complexe to include it in the build process.
>>>>>
>>>>
>>>> The MPA angle is indeed easier, deployment wise.
>>>> We'll look into the SPA case in more details including discussion with 
>>>> various framework authors.
>>>>
>>>> I hope this was useful.
>>>>  
>>>>
>>>>>
>>>>> Just wanted to share my feeling about this whole topic.
>>>>>
>>>>>  
>>>>>
>>>>> Thanks
>>>>>
>>>>>  
>>>>>
>>>>> Regards
>>>>>
>>>>>  
>>>>>
>>>>> *Thomas BIANCONI*
>>>>>
>>>>> Head of Data Technologies
>>>>>
>>>>> & Data Privacy Champion
>>>>>
>>>>> Global CDMO Team
>>>>>
>>>>> 41 Rue Martre - 92110 Clichy
>>>>>
>>>>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>>>>>
>>>>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>>>>>
>>>>> *E-mail* : thomas@loreal.com
>>>>>
>>>>> --
>>>>> *De :* Chris Harrelson 
>>>>> *Envoyé :* mercredi 2 mars 2022 18:51
>>>>> *À :* Daisuke Enomoto 
>>>>> *Cc :* blink-dev ; las...@chromium.org <
>>>>> las...@chromium.org>; pme...@chromium.org ; 
>>>>> Francesco Montanari ; Maxim Makarov <
>>>>> maxpa...@gmail.com>; b...@chromium.org ; 
>>>>> dsch...@chromium.org ; ians...@chromium.org <
>>>>> ians...@chromium.org>; rektide ; Ben Lesh <
>>>>> b...@benlesh.com>; Andrew Wilder ; Vito De 
>>>>> Giosa 
>>>>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC 
>>>>> server push 
>>>>>  
>>>>> Notice: External mail 
>>>>> 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

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Daisuke Enomoto]

> If I understand correctly, I believe that there is some misunderstanding
>>> about Early Hints.
>>> Clearly, it's on us to make this easier to understand. Sorry...
>>> We'll put extra efforts in providing clear & detailed developer
>>> documentation when Early Hints ships.
>>>
>>> In the meantime, here is a high level summary of what Early Hints is,
>>> and how it works:
>>>
>>>1. Early Hints is a status code (103) which is used in HTTP
>>>responses while the server is preparing the final response. This
>>>intermediate response can include other HTTP headers, in particular LINK
>>>REL headers such as preload or preconnect.
>>>2. In some cases, it can take time for the server to prepare the
>>>main response: accessing the DB, having an edge cache go talk to the 
>>> origin
>>>server, etc. So, the idea is to speed up overall page load times by 
>>> giving
>>>the browser hints about what it might do while waiting for the actual
>>>response. Typically, the hints are about critical sub-resources or 
>>> origins
>>>which would be used by the final response.
>>>3. The browser processes these hints, and decides to preconnect or
>>>preload any missing origins/resources while waiting for the final 200 OK
>>>response (usually containing the main resource). Since the browser got 
>>> some
>>>work done ahead of time, the overall page load time is improved.
>>>
>>> In other words, the key point here is that Early Hints doesn't start
>>> during the HTML parsing: it starts with the non-final response headers, way
>>> before HTML parsing kicks in since that is blocked on the final response.
>>>
>>> See this section of the RFC
>>> <https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.>
>>> for an example of how this looks at the HTTP level.
>>>
>>>
>>>
>>>
>>>> Regarding the complexity to put it in place early hints is easy when
>>>> you serve different page but for Single Page Application the build process
>>>> don't generate differentiate serving based on the route since the routing
>>>> of the application is generally managed in the frontend.
>>>> So for Single Page Application to managed server push not global to all
>>>> route it will more complexe to include it in the build process.
>>>>
>>>
>>> The MPA angle is indeed easier, deployment wise.
>>> We'll look into the SPA case in more details including discussion with
>>> various framework authors.
>>>
>>> I hope this was useful.
>>>
>>>
>>>>
>>>> Just wanted to share my feeling about this whole topic.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> *Thomas BIANCONI*
>>>>
>>>> Head of Data Technologies
>>>>
>>>> & Data Privacy Champion
>>>>
>>>> Global CDMO Team
>>>>
>>>> 41 Rue Martre - 92110 Clichy
>>>>
>>>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>>>>
>>>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>>>>
>>>> *E-mail* : thomas.bianc...@loreal.com
>>>>
>>>> --
>>>> *De :* Chris Harrelson 
>>>> *Envoyé :* mercredi 2 mars 2022 18:51
>>>> *À :* Daisuke Enomoto 
>>>> *Cc :* blink-dev ; las...@chromium.org <
>>>> las...@chromium.org>; pme...@chromium.org ;
>>>> Francesco Montanari ; Maxim Makarov <
>>>> maxpain...@gmail.com>; b...@chromium.org ;
>>>> dsch...@chromium.org ; ians...@chromium.org <
>>>> iansw...@chromium.org>; rektide ; Ben Lesh <
>>>> b...@benlesh.com>; Andrew Wilder ; Vito De
>>>> Giosa 
>>>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC
>>>> server push
>>>>
>>>> Notice: External mail
>>>> 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
>>

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenji Baheux]

epare the main
>>response: accessing the DB, having an edge cache go talk to the origin
>>server, etc. So, the idea is to speed up overall page load times by giving
>>the browser hints about what it might do while waiting for the actual
>>response. Typically, the hints are about critical sub-resources or origins
>>which would be used by the final response.
>>3. The browser processes these hints, and decides to preconnect or
>>preload any missing origins/resources while waiting for the final 200 OK
>>response (usually containing the main resource). Since the browser got 
>> some
>>work done ahead of time, the overall page load time is improved.
>>
>> In other words, the key point here is that Early Hints doesn't start
>> during the HTML parsing: it starts with the non-final response headers, way
>> before HTML parsing kicks in since that is blocked on the final response.
>>
>> See this section of the RFC
>> <https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.>
>> for an example of how this looks at the HTTP level.
>>
>>
>>
>>
>>> Regarding the complexity to put it in place early hints is easy when you
>>> serve different page but for Single Page Application the build process
>>> don't generate differentiate serving based on the route since the routing
>>> of the application is generally managed in the frontend.
>>> So for Single Page Application to managed server push not global to all
>>> route it will more complexe to include it in the build process.
>>>
>>
>> The MPA angle is indeed easier, deployment wise.
>> We'll look into the SPA case in more details including discussion with
>> various framework authors.
>>
>> I hope this was useful.
>>
>>
>>>
>>> Just wanted to share my feeling about this whole topic.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> *Thomas BIANCONI*
>>>
>>> Head of Data Technologies
>>>
>>> & Data Privacy Champion
>>>
>>> Global CDMO Team
>>>
>>> 41 Rue Martre - 92110 Clichy
>>>
>>> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>>>
>>> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>>>
>>> *E-mail* : thomas.bianc...@loreal.com
>>>
>>> --
>>> *De :* Chris Harrelson 
>>> *Envoyé :* mercredi 2 mars 2022 18:51
>>> *À :* Daisuke Enomoto 
>>> *Cc :* blink-dev ; las...@chromium.org <
>>> las...@chromium.org>; pme...@chromium.org ;
>>> Francesco Montanari ; Maxim Makarov <
>>> maxpain...@gmail.com>; b...@chromium.org ;
>>> dsch...@chromium.org ; ians...@chromium.org <
>>> iansw...@chromium.org>; rektide ; Ben Lesh <
>>> b...@benlesh.com>; Andrew Wilder ; Vito De
>>> Giosa 
>>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server
>>> push
>>>
>>> Notice: External mail
>>> 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 t

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

5%2095>
>>
>> *E-mail* : thomas.bianc...@loreal.com
>>
>> --------------
>> *De :* Chris Harrelson 
>> *Envoyé :* mercredi 2 mars 2022 18:51
>> *À :* Daisuke Enomoto 
>> *Cc :* blink-dev ; las...@chromium.org <
>> las...@chromium.org>; pme...@chromium.org ;
>> Francesco Montanari ; Maxim Makarov <
>> maxpain...@gmail.com>; b...@chromium.org ;
>> dsch...@chromium.org ; ians...@chromium.org <
>> iansw...@chromium.org>; rektide ; Ben Lesh <
>> b...@benlesh.com>; Andrew Wilder ; Vito De Giosa
>> 
>> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server
>> push
>>
>> Notice: External mail
>> 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 
>> wrote:
>>
>> Hello,
>>
>> We conducted an experiment for Early Hints (chromestatus
>> <https://urldefense.com/v3/__https://chromestatus.com/feature/5207422375297024__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzNtkXfmC$>)
>> 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$>
>> 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$>
>> 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  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
>>

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenji Baheux]

Hi Thomas,

I'm part of the team working on Early Hints.

On Wed, Mar 16, 2022 at 6:58 AM BIANCONI Thomas 
wrote:

> I am sad to read this...
> A new step before the deprecation of server push.
>
> I would love to see comparaison in term of performance between server push
> and early hint.
> On a pure theoric point of view early hint starts during the html parsing
> whereas the server push start with the response header. So server push by
> design is better.
>

If I understand correctly, I believe that there is some misunderstanding
about Early Hints.
Clearly, it's on us to make this easier to understand. Sorry...
We'll put extra efforts in providing clear & detailed developer
documentation when Early Hints ships.

In the meantime, here is a high level summary of what Early Hints is, and
how it works:

   1. Early Hints is a status code (103) which is used in HTTP responses
   while the server is preparing the final response. This intermediate
   response can include other HTTP headers, in particular LINK REL headers
   such as preload or preconnect.
   2. In some cases, it can take time for the server to prepare the main
   response: accessing the DB, having an edge cache go talk to the origin
   server, etc. So, the idea is to speed up overall page load times by giving
   the browser hints about what it might do while waiting for the actual
   response. Typically, the hints are about critical sub-resources or origins
   which would be used by the final response.
   3. The browser processes these hints, and decides to preconnect or
   preload any missing origins/resources while waiting for the final 200 OK
   response (usually containing the main resource). Since the browser got some
   work done ahead of time, the overall page load time is improved.

In other words, the key point here is that Early Hints doesn't start during
the HTML parsing: it starts with the non-final response headers, way before
HTML parsing kicks in since that is blocked on the final response.

See this section of the RFC
<https://datatracker.ietf.org/doc/html/rfc8297#:~:text=The%20following%20example%20illustrates%20a%20typical%20message%20exchange%20that%0A%20%20%20involves%20a%20103%20(Early%20Hints)%20response.>
for an example of how this looks at the HTTP level.




> Regarding the complexity to put it in place early hints is easy when you
> serve different page but for Single Page Application the build process
> don't generate differentiate serving based on the route since the routing
> of the application is generally managed in the frontend.
> So for Single Page Application to managed server push not global to all
> route it will more complexe to include it in the build process.
>

The MPA angle is indeed easier, deployment wise.
We'll look into the SPA case in more details including discussion with
various framework authors.

I hope this was useful.


>
> Just wanted to share my feeling about this whole topic.
>
>
>
> Thanks
>
>
>
> Regards
>
>
>
> *Thomas BIANCONI*
>
> Head of Data Technologies
>
> & Data Privacy Champion
>
> Global CDMO Team
>
> 41 Rue Martre - 92110 Clichy
>
> *Mob* : +33 (0) 6 15 35 33 57 <+33%206%2015%2035%2033%2057>
>
> *Ph* : +33 (0) 1 47 56 45 95 <+33%201%2047%2056%2045%2095>
>
> *E-mail* : thomas.bianc...@loreal.com
>
> --
> *De :* Chris Harrelson 
> *Envoyé :* mercredi 2 mars 2022 18:51
> *À :* Daisuke Enomoto 
> *Cc :* blink-dev ; las...@chromium.org <
> las...@chromium.org>; pme...@chromium.org ;
> Francesco Montanari ; Maxim Makarov <
> maxpain...@gmail.com>; b...@chromium.org ;
> dsch...@chromium.org ; ians...@chromium.org <
> iansw...@chromium.org>; rektide ; Ben Lesh <
> b...@benlesh.com>; Andrew Wilder ; Vito De Giosa <
> vito.degi...@gmail.com>
> *Objet :* Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server
> push
>
> Notice: External mail
> 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 finishe

RE: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[BIANCONI Thomas]

I am sad to read this...
A new step before the deprecation of server push.

I would love to see comparaison in term of performance between server push and 
early hint.
On a pure theoric point of view early hint starts during the html parsing 
whereas the server push start with the response header. So server push by 
design is better.
Regarding the complexity to put it in place early hints is easy when you serve 
different page but for Single Page Application the build process don't generate 
differentiate serving based on the route since the routing of the application 
is generally managed in the frontend.
So for Single Page Application to managed server push not global to all route 
it will more complexe to include it in the build process.

Just wanted to share my feeling about this whole topic.

Thanks

Regards

Thomas BIANCONI
Head of Data Technologies
& Data Privacy Champion
Global CDMO Team
41 Rue Martre - 92110 Clichy
Mob : +33 (0) 6 15 35 33 57
Ph : +33 (0) 1 47 56 45 95
E-mail : thomas.bianc...@loreal.com<mailto:thomas.bianc...@loreal.com>


De : Chris Harrelson 
Envoyé : mercredi 2 mars 2022 18:51
À : Daisuke Enomoto 
Cc : blink-dev ; las...@chromium.org 
; pme...@chromium.org ; Francesco 
Montanari ; Maxim Makarov 
; b...@chromium.org ; 
dsch...@chromium.org ; ians...@chromium.org 
; rektide ; Ben Lesh 
; Andrew Wilder ; Vito De Giosa 

Objet : Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

Notice: External mail

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 
mailto:denom...@chromium.org>> wrote:

Hello,


We conducted an experiment for Early Hints 
(chromestatus<https://urldefense.com/v3/__https://chromestatus.com/feature/5207422375297024__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzNtkXfmC$>)
 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$>
 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://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$>
 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 
mailto: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 fo

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Chris Harrelson]

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 
wrote:

> Hello,
>
> We conducted an experiment for Early Hints (chromestatus
> ) 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
>  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  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  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.
>> 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Daisuke Enomoto]

Hello,

We conducted an experiment for Early Hints (chromestatus
) 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 
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
 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  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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Mitar]

Hi!

So I finally got to experiment a bit with HTTP2 push, preload link
header, and 103 early hints and to compare them, especially in the
context of API endpoints (similar to Vulcain [1]). My observations
are:

Go does not yet support 103 Early hints (but PRs exist [2][3]). 103
Early hints seem to be very verbose if the main use case is to send
preload link headers: "rel=preload;" could be maybe just implied? And
if I want to specify "crossorigin=use-credentials" across multiple
links, it becomes repetitive. Maybe it would be simpler to have 103
Preload with slightly modified syntax which would allow one to group
preload links together based on attributes.

Using a regular preload link header seems to be acted upon only after
both HTTP headers and response body has been consumed by the browser.
So it seems to me that the whole 103 Early hints is just because
browsers do not process HTTP headers immediately when they receive
them (if I force flush them before even sending the response body).
Make me wonder if it would not be easier to standardize early
processing of HTTP headers and early acting upon link headers in there
instead of the whole 103 Early hints approach which requires new
support across the full HTTP stack. Am I missing something here? Why
do we even need 103 Early hints?

HTTP2 push is even in 2022 sadly lacking high quality support across
the stack and this makes it hard to use. Go does not support it in
HTTP client library [4] and doing HTTP pushes seems to be slow [5].
Nor Chrome nor Firefox provide any insights into HTTP pushes in
developer tools, so it is really hard to observe them and debug them
(timings, headers, have they been canceled by the browser, informing a
developer if HTTP push has not been used). With such bad support
across the stack I do not wonder anymore why people have a hard time
using HTTP pushes and using them effectively.

So my conclusion is: given how hard it is to get HTTP pushes to be
implemented across the stack, I worry that the same thing will happen
with 103 Early hints. E.g.: will they be and how will they be exposed
in developer tools? How will one be able to observe when they are in
effect and when they are not? I wonder if in 5 years we will not be at
the same point thinking about removing 103 Early hints. Maybe simply
do early processing of HTTP headers and acting upon any link headers
in there might be much simpler to both implement and expose in
developer tools in browsers (almost no work needed there, only
resources will be fetched earlier in timelines). And no need for any
changes to the rest of the HTTP stack.

[1] https://github.com/dunglas/vulcain
[2] https://github.com/golang/go/pull/42597
[3] https://github.com/golang/net/pull/96
[4] https://github.com/golang/go/issues/18594
[5] https://github.com/golang/go/issues/51361


Mitar



Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
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/CAKLmikPu72BG56Jng13iu-JLQ5iw4v97D%3DvhmaP5-pF4JT_ydw%40mail.gmail.com.

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Morgaine]

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  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 

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenichi Ishibashi]

Clarification: I'm talking about the experiment evaluating the effect of
using Early Hints. We have been collaborating with a CDN and their
customers for the experiment.

On Thu, Dec 9, 2021 at 9:08 AM Kenichi Ishibashi  wrote:

> We have early results that indicate improvements on FCP/LCP. We'd like to
> talk to some experiment participants to confirm these results.
>
> On Thu, Dec 9, 2021 at 3:06 AM yue li  wrote:
>
>> It's 3 weeks now, we're waiting for the update. Anything I missed?
>>
>> 在2021年11月17日星期三 UTC+8 00:08:26 写道：
>>
>>> Hi,
>>>
>>> We are waiting on results from an ongoing experiment to confirm that
>>> Early Hints works and improves performance. There should be an update
>>> in three weeks.
>>>
>>> Bence
>>>
>>> On Thu, Nov 11, 2021 at 7:50 PM Daniel Micay 
>>> wrote:
>>> >
>>> > It's now a year since the removal of HTTP/2 push was announced and
>>> Chromium still has HTTP/2 push. Are you waiting until browsers and servers
>>> implement 103 Early Hints? We use push but we halted optimizing it further
>>> due to the announced removal.
>>>
>> --
>> 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/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org
>> 
>> .
>>
>

-- 
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/CAPLXX-92vOHGifkccRS9oGh84aMmoBu0OCTX23xacn0PTnJBgg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Kenichi Ishibashi]

We have early results that indicate improvements on FCP/LCP. We'd like to
talk to some experiment participants to confirm these results.

On Thu, Dec 9, 2021 at 3:06 AM yue li  wrote:

> It's 3 weeks now, we're waiting for the update. Anything I missed?
>
> 在2021年11月17日星期三 UTC+8 00:08:26 写道：
>
>> Hi,
>>
>> We are waiting on results from an ongoing experiment to confirm that
>> Early Hints works and improves performance. There should be an update
>> in three weeks.
>>
>> Bence
>>
>> On Thu, Nov 11, 2021 at 7:50 PM Daniel Micay  wrote:
>> >
>> > It's now a year since the removal of HTTP/2 push was announced and
>> Chromium still has HTTP/2 push. Are you waiting until browsers and servers
>> implement 103 Early Hints? We use push but we halted optimizing it further
>> due to the announced removal.
>>
> --
> 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/5bf6cbf0-3b96-4bdd-9a9a-cb1f10b76f1fn%40chromium.org
> 
> .
>

-- 
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/CAPLXX-_GqnRzU8Bb9fUwNjc93AtLeD3YoBeR9ztdh4S%3DCfXX4Q%40mail.gmail.com.

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Bence Béky]

Hi,

We are waiting on results from an ongoing experiment to confirm that
Early Hints works and improves performance.  There should be an update
in three weeks.

Bence

On Thu, Nov 11, 2021 at 7:50 PM Daniel Micay  wrote:
>
> It's now a year since the removal of HTTP/2 push was announced and Chromium 
> still has HTTP/2 push. Are you waiting until browsers and servers implement 
> 103 Early Hints? We use push but we halted optimizing it further due to the 
> announced removal.

-- 
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/CACMu3trb2cyfv6TdUeCWL1u1cwDUf0HSZEWjfnjayH3UqYCf%2BQ%40mail.gmail.com.

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Daniel Micay]

It's now a year since the removal of HTTP/2 push was announced and Chromium 
still has HTTP/2 push. Are you waiting until browsers and servers implement 103 
Early Hints? We use push but we halted optimizing it further due to the 
announced removal.

-- 
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/d95de47c-3770-4a1c-bfd2-d2892704439en%40chromium.org.

[blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push

[Joel Szegedin]

One of the main reasons why consumers have not adopted to use HTTP/2 Server 
Push is because usage would be centralized to static content, yet most CDN 
providers have not yet implemented a usable Architecture for HTTP/2 Push.

So rather than removing this useful feature (yes, it's useful), perhaps 
work with CDN providers to implement this feature so it can be utilized 
properly.

On Wednesday, June 30, 2021 at 12:23:35 PM UTC-4 Vito De Giosa 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  
>>> 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, s 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