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