Hi! Done: https://bugs.chromium.org/p/chromium/issues/detail?id=1415291
Mitar On Wed, Nov 2, 2022 at 11:46 PM Mike Taylor <miketa...@chromium.org> wrote: > > Hi Mitar, > > This is really good feedback. Would you mind filing a bug at > crbug.com/new? Feel free to respond here with the link. > > thanks, > Mike > > On 11/1/22 11:25 AM, Mitar wrote: > > 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/CAKLmikP19rmngMvjxC-n4cGrSYbMShXdvTYJzTT0Mi019pJwdg%40mail.gmail.com.
