Fonts and crossorigin

[yoavweiss]

If I'm reading obtain the preload resource properly, it'd mean that if a user want to preload a font, they would have to add a crossorigin attribute to the <link>.

I wonder if that the best way to go, or we should special case font to implicitly set crossorigin.
I tend to think special casing font would be better, since users won't have to worry about that. I worry that otherwise, omitting crossorigin and double-downloading the font would be a common error.

In any case, we should address this in the spec: Either change the processing model, or change the examples and add a note.

[igrigorik]

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

[yoavweiss]

I don't think we can omit crossorigin setting for preload. If we do, (as one example) how would the developer preload an <img crossorigin ... > resource?

Yeah, I wasn't suggesting that we omit crossorigin, just that we implicitly set it for fonts.

As for fonts getting special treatment.. this seems like a bit too much magic. I think it may be even more confusing for fonts to transparently opt-in into this mode, whereas you'd have to still specify the crossorigin attribute for other use cases.

I agree it's magical, but that's already what fonts do... OTOH, I can live with users having to explicitly set crossorigin. FWIW, if we'd see this mistake a lot in the wild, we can always implicitly set crossorigin for font later.

So, if we go that route, we need to change the font examples in the spec, and probably add a note.

[igrigorik]

@annevk what happens when I'm self-hosting the font on same origin as the document? Do we force the same flag and cause the UA to open a separate connection? (That would be unfortunate)

Put another way, are there ever cases where fonts are exempt from forcing crossorigin? Do we ever see this behavior changing?

[annevk]

I think "anonymous" in implementations means that the credentials mode is "same-origin", but someone would have to verify that to be sure.

[igrigorik]

I believe that is the case for Chrome.. /cc @mikewest for a sanity check.

@yoavweiss the examples in the spec are all same-origin so I don't think it's strictly necessary to add it? That said, perhaps we should change one of the examples to use a different origin with crossorigin..

[mikewest]

I think that's correct, yes.

I also don't think we should special case <link> for fonts.

[yoavweiss]

Fair enough.

In that case, let's just add a different origin example for a font that includes a crossorigin attribute.

[yoavweiss]

I believe there's some disagreement between the Blink implementation and the spec examples, which we need to sort out.

Currently, Blink's implementation requires the crossorigin attribute also on same-origin font fetches, which means that the spec examples won't work with it.

An IRC conversation with @annevk made me believe that Blink's implementation is right to do so, but re-reading that, I may have asked the wrong question.

Looking at the fonts spec, it fetches fonts with potentially CORS-enabled fetch, which AFAICT would result in "same-origin" fetch for the same-origin case. OTOH, the fetch spec is supposed to supplant the above behavior, but I'm not sure where is that behavior defined.

So, should the preload of fonts from the same origin use the crossorigin attribute? If not, we need to fix Blink's behavior. If it should, we need to fix our examples.

[annevk]

If the URL is same-origin the crossorigin attribute has no effect (mode will be "cors", but it doesn't matter).

[yoavweiss]

Can you elaborate on that?

• If a font is fetched from the same origin, what should be the mode? "cors" or "same-origin"? Could you point me to the spec sections that define that?
• Assuming the answer to the above point is "cors", are you saying that same origin "cors" mode requests and same-origin "same-origin" requests can be interchangeably reused?

[annevk]

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

[igrigorik]

CSS doesn't define its integration with Fetch, but Fetch' mode doesn't depend on the URL. (I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

Hmm... doesn't the possibility of a redirect force us to treat them as different? As in, I give you a same-origin URL and mark it as crossorigin=anonymous: the request hits the URL and gets back a 3XX to another origin, at which point we have to open a new socket... And while all that is happening, we need to be able to match this in-flight request against other requests asking for same URL, to avoid duplicate downloads.

Also, as far as I understand, one of the motivations behind potentially cors-enabled flag for fonts was to avoid cookies.. which, at least in theory, is applicable to both same and cross-origin cases. (With one big gotcha that fonts require a dedicated socket -- ugh).

[annevk]

Cookies are included for same-origin requests, unless you specify "omit" for credentials mode, which almost nothing can do (fetch() and new Worker() can, iirc). Opening a new socket when you cross origins also seems entirely reasonable, given the same-origin policy. Not entirely sure what we're discussing at this point.

[yoavweiss]

@igrigorik - seems like both Chrome and Firefox send cookies on same origin font fetches. Regarding the redirect scenario, cross-origin redirects should be CORS, but I don't think it means (or should mean) that non-redirect responses to same-origin requests should not match, nor that same-origin font requests can't use the general socket pool.

Adding @sleevi for Opinions™

(I think that if there are no cross-origin redirects, "cors" and "same-origin" are equivalent for a same-origin URL.)

@annevk - Is that defined in Fetch? Also, is "potentially CORS-enabled fetch" defined?

[annevk]

Is that defined in Fetch?

I think it follows from what Fetch defines, yes.

"potentially CORS-enabled fetch" is no longer a thing. It used to be a thing in the HTML standard, but we removed that some months back.

It seems however y'all are quite confused. The socket pool is effectively keyed on origin/credentials. The key for a same-origin fetch will be the origin/true and for a cross-origin fetch will be the origin/false (since the credentials mode for fonts is "same-origin" and the mode will always be "cors").

[sleevi]

Having read this thread several times since @yoavweiss reached out, I'm still quite confused as to what "the issue" is. But so far everything @annevk has said sounds right.

[yoavweiss]

OK, let me try to clarify.
Currently, the Chrome implementation requires the addition of a "crossorigin" attribute when preloading fonts from same-origin, or the preloaded resource doesn't match the one requested later on, resulting in a double download.

The issue is me trying to figure out if this is a bug, or if this is the expected behavior and the spec examples should be modified accordingly.
From @annevk's comments I understand that this is an implementation issue.