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.

[blink-dev] Blink bug status as of 2022-07-11

[tkent]

Title: Blink bug summary




Blink bug status as of 2022-07-11

Component
Open


Slow Triage
Pri-0/1



⭐
No owner
Oldest


Whole Blink16,900(+74)72,505(-57)1,030(+9)1,042(+20)317Jan 2015
Uncategorized151602(-3)2Jul 2022
Blink>Accessibility389(+12)1,358(+10)2(+2)3212Jul 2019
Blink>Animation250(-3)1,396(-4)011(-2)6Nov 2020
Blink>AppManifest30196231Jan 2020
Blink>AudioOutputDevices1138210Jun 2022
Blink>BackgroundFetch38(-1)64(-1)18208Sep 2018
Blink>BackgroundSync1544543Nov 2020
Blink>BatteryStatus11558(+1)33Nov 2016
Blink>Bindings285(-4)1,030(-7)8(-1)23(+1)8Apr 2016
Blink>Bluetooth118598(+1)022Jan 2020
Blink>CSS483(+9)3,579(+19)3(+2)5(+3)0Jul 2022
Blink>Canvas324(+3)1,311(+6)7(-2)110Jun 2016
Blink>CaptureFromElement2076421Feb 2022
Blink>Compositing201(+1)757(+1)2(+1)00
Blink>Contacts1128120Apr 2020
Blink>ContentIndexing525110May 2020
Blink>DOM211(-1)964(-3)03(+1)0Jun 2022
Blink>DataTransfer278(+2)1,281(+4)4(+2)133Nov 2017
Blink>DocumentMetadata1124211Feb 2020
Blink>Editing977(+16)3,835(+13)6(+1)18(+13)13Apr 2021
Blink>EnumerateDevices28(-1)119(+1)410Feb 2022
Blink>FeaturePolicy4816119(+1)77Jun 2021
Blink>FencedFrames68163(-1)17(-1)19(+1)11May 2021
Blink>FoldableAPIs652(+2)000
Blink>Fonts366(+2)1,898(+8)9(-2)2(+1)1Jul 2022
Blink>Forms436(+3)2,129(+10)12(-2)0May 2021
Blink>Fullscreen772742(+2)3(-1)0Aug 2020
Blink>GamepadAPI111406020Feb 2019
Blink>GarbageCollection144(-6)412(-12)09(+2)2Jan 2020
Blink>Geolocation51(+2)317(+1)07(+1)2May 2018
Blink>Geometry47154000
Blink>GetDisplayMedia175(+2)612(+2)16(+2)232Jul 2020
Blink>GetUserMedia119(+1)562(+3)19170Jan 2021
Blink>HID42150(+2)000
Blink>HTML494(-5)2,208(+6)02(-3)0Jun 2022
Blink>Handwriting56400
Blink>History36148(+1)110Oct 2021
Blink>HitTesting42(+1)176000
Blink>Identity87(-10)195(-24)15(-1)25(-7)2May 2021
Blink>Image109(+1)594(+2)2(+2)1(+1)1Jun 2022
Blink>ImageCapture21(+1)78(+1)500
Blink>Infra140(+2)442(+2)17(+2)30May 2022
Blink>Input788(+3)2,839(-5)1(+1)36(-3)19Apr 2019
Blink>InterestCohort49100
Blink>InterestGroups49(+1)111(+1)22(+1)51Feb 2021
Blink>Internals224(-2)680(-11)118(-3)37(-1)21Aug 2017
Blink>_javascript_1,0102,888(-10)47(-2)104(-5)17Aug 2015
Blink>Layout1,002(+32)5,697(-36)3(-4)33(+19)21Aug 2021
Blink>LazyLoad44(+1)198(+1)000
Blink>Loader5082,357(-5)3(-3)18(+1)4Feb 2017
Blink>Managed1(-1)1(-3)00(-1)0
Blink>MathML30368(+2)011Jun 2020
Blink>Media917(-1)3,279(-21)80(+4)10529Aug 2015
Blink>MediaRecording44(-2)237(-22)511Feb 2021
Blink>MediaStream96(+1)487(+1)186(-1)0Feb 2021
Blink>MemoryAllocator194(+2)650(+3)11(+1)433Sep 2015
Blink>Messaging40(+3)149(+4)23(+1)9(+2)4Jan 2018
Blink>NFC635000
Blink>Network445(-5)2,267(-11)12(-1)42(-1)10Aug 2015
Blink>PageLifecycle612322721Aug 2017
Blink>Paint653(+16)2,339(+35)4(+3)11(+8)2Jul 2021
Blink>Payments143(+2)412(+2)1(+1)3(+1)0Oct 2019
Blink>PerformanceAPIs197(-3)782(-7)2(-1)60Apr 2022
Blink>PermissionsAPI371571320Oct 2021
Blink>Portals133(-1)411(-3)14137Mar 2020
Blink>PresentationAPI42(+1)140(+1)04(+1)0May 2019
Blink>Previews22000
Blink>PrivateAggregation1827000
Blink>PushAPI31139621Jul 2021
Blink>ReportingObserver719010Aug 2021
Blink>SVG321(+2)1,888(+5)1(+1)3(+2)3Feb 2022
Blink>SavePage11274483(+1)74Jan 2015
Blink>Scheduling241(-1)1,881105(-2)11(-1)1Oct 2017
Blink>Screen26(+1)75(+2)1(+1)20Apr 2022
Blink>ScreenOrientation28752122Feb 2021
Blink>Scroll7502,759(+6)0(-2)4025Dec 2019
Blink>SecurityFeature5492,401(+16)240(-2)7Sep 2017
Blink>Sensor25146(+1)010Apr 2020
Blink>Serial28143010Jun 2021
Blink>ServiceWorker315(-2)1,755(+4)3(-1)71Sep 2021
Blink>ShapeDetection26111021Jun 2019
Blink>Speech114(+1)535(+2)88(-1)73Sep 2019
Blink>Storage605(+3)3,520(-6)2(+1)57(+1)16Sep 2015
Blink>TextAutosize25242(+1)000
Blink>TextEncoding24(-2)92(-6)6(-2)33Jul 2021
Blink>TopicsAPI6152(+1)40Jan 2022
Blink>URLPattern4(+1)7(+1)1(+1)00
Blink>USB38197020Jan 2021
Blink>Vibration11251000
Blink>ViewSource17162000
Blink>WakeLock9(+1)55(+4)100
Blink>WebAudio153715271Oct 2020
Blink>WebAuthentication111(+1)374(+1)24196Jan 2020
Blink>WebCrypto23631400
Blink>WebFonts27(-1)124(-3)200
Blink>WebGL654(-3)2,235(-8)5(+1)22(-4)3Jun 2020
Blink>WebGPU125(+3)404(+6)418(+2)2Jun 2021
Blink>WebHD12000
Blink>WebMIDI26129320Nov 2016
Blink>WebML926500
Blink>WebOTP361651330Sep 2020
Blink>WebRTC509(-3)2,801(-25)32(-2)56(+1)9Feb 2018
Blink>WebShare492644(+1)11Aug 2021
Blink>WebXR99(-1)406(-3)2(+2)00
Blink>WindowDialog65588(+2)010Mar 2020
Blink>Workers155(-2)84702(-1)2Aug 2021
Blink>XML32(-1)163(-6)000



A value is the number of bugs in a component and its sub-components.
e.g. The 'Blink>Layout' row contains all of bugs in sub-components of
Blink>Layout in addition to Blink>Layout bugs.
The data was fetched with a permission of a general @google.com account.
It takes account of non-public bugs, but doesn't have the owner field and
the open date field of Restrict-View bugs.
Links from delta parts in the 'Open' columns don't represent
anchor numbers precisely because a query depends on the currnet date and
it doesn't contain issues of which component was changed

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.