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.
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, just like if they were being fetched as part of the page. I don't know off the top of my head if GET <- 401 -> GET <- 103 <- 200 works in the current implementation but I could easily see. the case for filing an issue and making sure it does if it doesn't. Authorization is not a response header and preload has no way of specifying arbitrary headers. Content negotiation works fine for "as" types that have "accept" types associated with them. It sounds like the concern there is around being able to specify arbitrary headers and overrides for "fetch" preloads specifically and that isn't supported by preload in any case (header or in markup). The PUSH case doesn't support custom authorization or content negotiation either. 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. HTTP/3 already has no equivalent (and neither does HTTP/1) and once all of the CDN's move from automatically creating PUSH frames from preload headers (likely replaced with using early hints and preload), usage on the web will be a rounding error away from zero. A much better approach would be to work with the loading team if you have a use case that is slow with how the web works today to see if there are solutions in the pipeline (or that can be generalized) that solve the issue more cleanly. For example, if you really want to serve subresources along with the main content, web bundles <https://web.dev/web-bundles/> is an application-level way that is being worked on to handle that case. On Sun, Jul 10, 2022 at 7:40 AM Mitar <mmi...@gmail.com> wrote: > Hi! > > On Mon, Apr 25, 2022 at 9:09 AM Kenji Baheux <kenjibah...@chromium.org> > wrote: > >> The Authorization header should be supported in Early Hints. >> Please share a concrete example if this doesn't work as you'd hope. >> > > Kenji, I think there is some misunderstanding here between what I am > concerned about (what is possible with HTTP2 push and not with Early Hints). > > So with Early Hints Authorization header is supported in the following way: > > HTTP/1.1 103 Early Hints > Link: /api/data.json; rel=preload; as=fetch > Authorization: Bearer foobar > > But this does not mean that the browser will use that header when doing a > request to preload the /api/data.json. So preloading resources which > require authorization is not possible with Early Hints. But it is possible > with HTTP2 push. > > Similar and related issue is with Accept header and content negotiation. > It is not possible to define a Link header which would for example request > application/json response, when multiple responses are possible. This has > been reported independently at [1]. > > So to me it looks like Early Hints support only simple public requests, no > authorization, no content negotiation. As such they are not suitable to > preload data from API endpoints. While HTTP2 push can support such use > cases. > > [1] https://bugs.chromium.org/p/chromium/issues/detail?id=962642 > > Am I missing something obvious about the Link header which would address > those concerns? > > > 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/CAPq58w5d0QGh7Z2Y_ejpeUm%3DwqC9CCnydP%2B9vn9hMVqB0zzJRw%40mail.gmail.com.
