Comment on Partially incorrect MIME type detection for files newly uploaded to the cloud
@Der Pepe (Hubzilla) ⁂
Maybe file an issue to libmagic?
I would rather not rely on file endings to determine the file mime type. We could possibly make an excemption for channels that have code right so that in that case if text/plain is returned from finfo() we compare it to the previously provided mimetype and if it is not the same, revert to the provided one. But i actually do not like this hack!
What could be done to ensure that CSS is recognised correctly and entered into the table?
Maybe file an issue to libmagic?
I would rather not rely on file endings to determine the file mime type. We could possibly make an excemption for channels that have code right so that in that case if text/plain is returned from finfo() we compare it to the previously provided mimetype and if it is not the same, revert to the provided one. But i actually do not like this hack!
I wouldn't like it either. But what are the chances that it will be fixed in libmagic within a reasonable timespan? Forget it; we need a usable workaround for the Hubzilla webpages ASAP.
My suggestion would be:
This is harmless, only affects CSS and should sort out the problem.
Sorry, but this won't work, as $os_rel_path is the hash, rather than the filename.
$filenameinstead of$os_relpath, soif ($mimetype === “text/plain” && preg_match(“/.css$/i”, $filename))Is that correct?