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