Google fonts api no longer returning woff files when the user agent is set to `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8`

[colmtroy]

Google fonts api no longer returning woff files when the user agent is set to `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8`

[siliconforks]

Let me provide an example which may help to explain the problem in more detail...

This is the Google Fonts URL for Open Sans:

https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&display=swap

If you access this URL with a modern user agent string, then you will get woff2 files:

curl --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36' 'https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&display=swap'

The URLs for the font files look like this:

https://fonts.gstatic.com/s/opensans/v40/memvYaGs126MiZpBA-UvWbX2vVnXBbObj2OVTS-muw.woff2

However, if you try using an older user agent string, you will get different results:

curl --user-agent 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8' 'https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&display=swap'

Then the URLs for the font files look like this:

https://fonts.gstatic.com/l/font?kit=memSYaGs126MiZpBA-UvWbX2vVnXBbObj2OVZyOOSr4dVJWUgshZ1x4gaVQUwaEQXjM&skey=62c1cbfccc78b4b2&v=v40

Now, if you try accessing that URL, the URL does in fact return a font file in woff format (the original woff format, not the newer woff2 format); however, the problem is that it's not clear how the client is supposed to know that it's a woff file:

1. The URL is kind of ugly and has no .woff file extension, so it gives no indication that it is a woff file. (Compare that to the URL for the woff2 files, which is simpler, cleaner, and has a clear .woff2 file extension.)

2. You might argue that clients are not really supposed to use the URL to determine the type of the file; they are supposed to use the Content-Type header. But that won't work either! The content-type returned is text/html; charset=utf-8. (Note that the content really is indeed a woff file, not an HTML document. It's just the Content-Type header that is wrong.)

So I'm not sure what the client is actually supposed to do here to determine that this is in fact a woff file. I tested using this font in web browsers and it does appear to work, so I would assume that browsers are sniffing the content to determine what type of file it is, which is not really an ideal solution. Ideally this font file would have a cleaner URL with a .woff file extension, or the Content-Type header would return the correct font/woff content-type, or (preferably) both. Note that the woff2 URL doesn't have these problems: the URL has a .woff2 extension clearly indicating the format, and if you access the URL you will find it returns the correct font/woff2 content-type.

Also, this is something which just changed in the last week or so. Before that the woff files used to have cleaner URLs with .woff extensions. (I'm not certain what the content-type was, but I'm guessing that probably used to be correct too.)

[mgirolet-gl]

So I'm not sure what the client is actually supposed to do here to determine that this is in fact a woff file.

You can determine the font's file format by reading the first few bytes of the file:

• If you read 77 4F 46 46 ('wOFF'), it's a .woff font
• If you read 77 4F 46 32 ('wOF2'), it's a .woff2 font
• If you read 00 01 00 00, it's a .ttf font
• If you read 4F 54 54 4F ('OTTO'), it's a .otf font
• If you read 4D 5A ('MZ'), it's a .fon font

Those are called "file signatures" or "magic bytes", there's a Wikipedia article that lists a lot of them.

Most programs use those to detect file formats, since relying on the good faith of the file provider to give the correct extension or the correct header often proves to be wrong.