mirror of
https://github.com/Crosstalk-Solutions/project-nomad.git
synced 2026-05-12 16:10:11 +02:00
fix(Downloads): treat missing Content-Type as octet-stream (#848)
download.kiwix.org (and some of its mirrors) don't always set a Content-Type header on .zim responses. The MIME validator was reading `headers['content-type'] || ''`, then running each allowlist entry through `''.includes(...)` which is always false, so every download from those hosts was rejected with `MIME type is not allowed`. RFC 7231 §3.1.1.5 says missing Content-Type may be treated as application/octet-stream by the recipient, and that's already in every binary-content allowlist we use (ZIM, PMTILES, base assets). Default the missing case to that and the validator does the right thing. Strict callers that don't list octet-stream still reject as before.
This commit is contained in:
parent
0a7bd9b11b
commit
e42f9331b6
|
|
@ -47,7 +47,14 @@ export async function doResumableDownload({
|
|||
timeout,
|
||||
})
|
||||
|
||||
const contentType = headResponse.headers['content-type'] || ''
|
||||
// Some upstream hosts (notably download.kiwix.org for .zim files) don't set a
|
||||
// Content-Type header at all. Per RFC 7231 §3.1.1.5, "if no Content-Type is
|
||||
// provided" the recipient may treat it as application/octet-stream — which is
|
||||
// already in every binary-content allowlist we use (ZIM, PMTILES, base assets).
|
||||
// Without this default, the validator below throws `MIME type is not allowed`
|
||||
// and breaks all downloads from kiwix's primary host (#848).
|
||||
const contentType =
|
||||
headResponse.headers['content-type'] || 'application/octet-stream'
|
||||
const totalBytes = parseInt(headResponse.headers['content-length'] || '0')
|
||||
const supportsRangeRequests = headResponse.headers['accept-ranges'] === 'bytes'
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user