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.

Reply via email to