FWIW, there's an independent feature request to enable preloading with arbitrary headers <https://github.com/w3c/preload/issues/157>.
On Sun, Jul 10, 2022 at 11:47 PM Patrick Meenan <pmee...@chromium.org> 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 <mmi...@gmail.com> wrote: > >> Hi! >> >> On Sun, Jul 10, 2022 at 4:19 PM Patrick Meenan <pmee...@chromium.org> >> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w7y_FUBmmzY2k1jSrqS%2BYSELDpBhTUR2anNLXwGw6TaRQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU80ahqMDgXbkJ95gL2zyYnC11ZgJOBTvofM26BFng2HQ%40mail.gmail.com.
