it is unclear which all as attribute values should be supported

[smaug----]

If I read correctly, all of https://fetch.spec.whatwg.org/#concept-request-destination or rather https://fetch.spec.whatwg.org/#concept-potential-destination should be supported, but the browsers which support rel=preload + as attribute don't seem to support all the values.
Chrome for example warns in the web console if one uses as="document", and the warning
is <link rel=preload> must have a valid 'as' value even tough document is per spec valid value.

Is there perhaps some subset of potential destination values which rel=preload should support?

[domfarolino]

I think they should all be supported. For the ones that are not supported by Chromium, I believe there are bugs for tracking the status (or in the audio/video case etc, spec bugs for I believe). Example: https://bugs.chromium.org/p/chromium/issues/detail?id=977033

[yoavweiss]

Yeah, we should also improve the console.log warnings to indicate the value is indeed valid, but not yet supported

[smaug----]

ok, if all the values should be supported, but aren't in practice, should UAs fire error or some other event on non-supported/non-implemented values?

[domfarolino]

That's a good question. I believe the only time the destination (as) is considered is in the preload-specific linked resource fetch setup steps return false. If these steps return false, no request should be made and no event should be fired, but otherwise, it seems the request should be made as usual. So I think Chrome's behavior is similar to these steps returning false (i.e., not treating certain destinations as valid states), though it is not currently specified that a user agent can do this.

[domfarolino]

FWIW I've filed https://crbug.com/1047945 to track improving Chrome's console warnings for unsupported destinations.

[yoavweiss]

I believe the only action related to this (improving Chromium's console warnings) is done. Closing but feel free to reopen if there's something I missed.