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