I see that cached-path currently determines how to extract an archive according to its filename extension:
|
if resource.ends_with(".tar.gz") { |
|
Ok(Self::TarGz) |
|
} else if resource.ends_with(".zip") { |
|
Ok(Self::Zip) |
|
} else { |
|
Err(Error::ExtractionError("unsupported archive format".into())) |
|
} |
The problem that I have is that some archives do not use the expected extension format (in my case, gzipped tarballs are using .tgz rather than .tar.gz). While this could be addressed by expanding/customising the extension list used by cached-path, perhaps it's also an opportunity to consider some alternative approaches:
- HTTP headers (namely
Content-Type and Content-Encoding);
- detection "magic" as per (or via) the
file(1) utility (there's also the magic and bindet crates—the former a wrapper around the libmagic C library and the latter not widely used, but both possibly useful here); or
- a user-provided format specifier?
Personally I feel that HTTP headers would be best (if available: obviously not the case for local resources), perhaps falling-back to magic and/or file extensions if no other option is available.
Happy to submit a PR with whatever approach you feel is most suitable for this library, even if only adding .tgz to existing extension list?
I see that
cached-pathcurrently determines how to extract an archive according to its filename extension:rust-cached-path/src/archives.rs
Lines 17 to 23 in db8cafb
The problem that I have is that some archives do not use the expected extension format (in my case, gzipped tarballs are using
.tgzrather than.tar.gz). While this could be addressed by expanding/customising the extension list used bycached-path, perhaps it's also an opportunity to consider some alternative approaches:Content-TypeandContent-Encoding);file(1)utility (there's also the magic and bindet crates—the former a wrapper around the libmagic C library and the latter not widely used, but both possibly useful here); orPersonally I feel that HTTP headers would be best (if available: obviously not the case for local resources), perhaps falling-back to magic and/or file extensions if no other option is available.
Happy to submit a PR with whatever approach you feel is most suitable for this library, even if only adding
.tgzto existing extension list?