Processing model for as?

[yoavweiss]

as for prefetch is not currently implemented in any browser AFAIK.

Its definition in the spec is somewhat problematic. It is described as optional, yet it's not clear what its processing should be:

• If it's identical to preload, it would mean that resource reuse rules, CSP and more should be driven from it.
  • That would mean that a missing as must pass connect-src policy and could only be reused by XHR and Fetch (assuming streaming issue is fixed. I'm not yet sure if it's a spec issue or an implementation one)
• Otherwise, as is not processed (other than perhaps for Accept headers), and we diverge from preload in its definition.

If we'd take the above route, treating as as optional will break backward compatibility with existing content out there.
If we don't, we would break consistency with preload, and surprise developers.

P.S. examples include as=html which is not a valid destination. Should be document? If so, how can we tell apart top-level navigation from an iframe?

[igrigorik]

My proposal is that we drop as for prefetch.

• Introducing it is not backwards compatible.
• Given that the primary use case is to fetch resources for next navigation, applying as CSP policy of the current page doesn't make sense. As a separate matter, perhaps we need a prefetch-src.. but let's keep that as a separate discussion.

[yoavweiss]

Highly related: prefetch requests don't seem to have a Fetch destination defined. I'll open an issue on the Fetch spec to define one.

/cc @annevk

[kinu]

Let me revive this thread a bit, but I can file a new issue if that's better. In a double-keyed cache world resources fetched for the current origin may not be reused in the next navigation if it crosses origins, and therefore prefetching subresources may not make a lot sense, unless they are made for the current navigation.

On the other hand main resource for top-level navigation seems to be able be safely prefetched and cached for the next navigation as the origin of resource == the origin of the navigation that is used. However this can work only if we have as= or something that specifies how / when the prefetched resource is used. If this sounds valid should we close this issue and keep as=?

Alternative proposal could be to limit prefetch only to be usable for top-level navigations, as prefetching subresources may not work in anyways in double-keyed cache world. Could it make sense or is it too limiting?

[ghost]

Alternative proposal could be to limit prefetch only to be usable for top-level navigations, as prefetching subresources may not work in anyways in double-keyed cache world.

I would argue the browser should be responsible for prefetching anything inside a nav element or using some kind of heuristics (e.g. device sensors by das) and next and prev should probably go along with it. Why add markup and spec when we can pit browser vendors against each other in competition.

[yoavweiss]

/cc @noamr

[noamr]

w3c/webappsec-csp#542 is my suggestion on how to handle this.
I believe as should be optional also for preload, and a preload without as should behave like a high-priority prefetch (e.g. use prefetch-src or fallback to the most lenient directive)

[yoavweiss]

Is there a use-case for as-less preload? IMO, preload withas is better (in terms of being able to determine priority, Accept headers as well as tight CSP rules)

[noamr]

Is there a use-case for as-less preload? IMO, preload withas is better (in terms of being able to determine priority, Accept headers as well as tight CSP rules)

I believe that having as is better, and would be good to have it also for prefetch, but for some cases it doesn't hurt to have it as-less. In some cases it could even be beneficial - e.g. using the same preload to display an image and to fetch it into an ArrayBuffer without having to make that decision when preloading/prefetching.

Besides those (minor?) use-cases, the main use case is ergonomic - to align prefetch and preload, and to provide good defaults when certain attributes are not necessary.

In any case, the other proposal also handles CSP for prefetch etc., it's not only about allowing as-less preloads.

[hiroshige-g]

I suspect Chromium implementation wouldn't be able to reuse as-less preload results within Blink's MemoryCache and preload cache, and thus have to retrieve the as-less-preloaded results from somewhere outside -- which is much more like prefetching.
Therefore, I imagine as-less preload would be mostly the same as prefetch.

[noamr]

I suspect Chromium implementation wouldn't be able to reuse as-less preload results within Blink's MemoryCache and preload cache, and thus have to retrieve the as-less-preloaded results from somewhere outside -- which is much more like prefetching. Therefore, I imagine as-less preload would be mostly the same as prefetch.

Maybe the same as prefetch but with a high fetching priority.

[yoavweiss]

Maybe the same as prefetch but with a high fetching priority.

What's the use case for that?

[noamr]

Maybe the same as prefetch but with a high fetching priority.

What's the use case for that?

#66 (comment)

When you're not sure exactly how your resource is going to be used, some resource types can be used in multiple ways.

Not sure this is a strong use-case, what I'm trying to do here is align prefetch and preload to make more sense and be in alignment with each other.

[yoavweiss]

OK, I think I understand the consistency argument.
At the same time, I'm concerned that this would result in developers misusing preload. Right now preloads without an as get ignored, and hence result in a neutral outcome - no optimization, but no damage either.

Once we allow preloads without as, developers would start using it, probably also in places where previously they'd be caught by console warnings and corrected. That can result in e.g. lack of proper content-negotiation for images (as the Accept headers would be off), resulting in bloated image downloads, and potentially cache mismatches once the real image request hits the cache.

[hiroshige-g]

Maybe the same as prefetch but with a high fetching priority.

If this has use cases, I feel this still should be <link rel="prefetch"> with high fetching priority (e.g. via Priority Hints), because exposing two things with similar DOM interface (preloads with and without as) but different underlying implementation and performance characteristics is probably confusing.

As for consistency, I feel the differences in as requirements between preload and prefetch is acceptable and reasonable, because preloading includes content-specific decoding (like image decoding etc.) and thus naturally requires as attribute, while prefetching is more like just network fetching, which doesn't necesarilly need as.

[noamr]

Maybe the same as prefetch but with a high fetching priority.

If this has use cases, I feel this still should be <link rel="prefetch"> with high fetching priority (e.g. via Priority Hints), because exposing two things with similar DOM interface (preloads with and without as) but different underlying implementation and performance characteristics is probably confusing.

As for consistency, I feel the differences in as requirements between preload and prefetch is acceptable and reasonable, because preloading includes content-specific decoding (like image decoding etc.) and thus naturally requires as attribute, while prefetching is more like just network fetching, which doesn't necesarilly need as.

Sure, I can get behind this.
But this leaves the question, do we want as for prefetch, perhaps as a way to guarantee image content-negotation, CSP etc?

[noamr]

as for prefetch is on a deprecation path.