HEAD request to get Content-Type of shared file no longer working

For a few years now, I've been able to use HEAD requests from my web page to verify that a Dropbox link that a user provides points to a "Content-Type: video/mp4" file

All of a sudden I get the following headers (some omitted for brevity):

Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Accept-Ranges, Content-Encoding, Content-Length, Content-Range, X-Dropbox-Metadata, X-Dropbox-Request-Id, X-JSON, X-Server-Response-Time, Timing-Allow-Origin, x-dropbox-pdf-password-needed
Cache-Control: max-age=60
Content-Disposition: inline; filename="Survive2018.mp4"; filename*=UTF-8''Survive2018.mp4
Content-Security-Policy: report-uri https://www.dropbox.com/csp_log?policy_name=blockserver-usercontent ; sandbox allow-forms allow-scripts allow-top-navigation allow-popups
Content-Security-Policy: form-action 'none' ; report-uri https://www.dropbox.com/csp_log?policy_name=blockserver-noscript ; script-src 'none'
Etag: 124921d
Pragma: public
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Dropbox-Content-Length: 3939168897
X-Robots-Tag: noindex, nofollow, noimageindex
X-Server-Response-Time: 56
Content-Type: application/json
Accept-Encoding: identity,gzip
Date: Thu, 10 Feb 2022 21:05:14 GMT
Server: envoy
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Robots-Tag: noindex, nofollow, noimageindex
X-Dropbox-Response-Origin: far_remote
X-Dropbox-Request-Id: 2acb520e314c461d966a55c73bb7b017
Transfer-Encoding: chunked

The content type is now set to "application/json". Is this by design or is it a bug? Does it have to do with "X-Content-Type-Options: nosniff"?

Thx!