Check filename extension to determine file type

[ebruchez]

We have #1838 about doing content sniffing, but that is a more elaborate fix to do.

Right now, we use the Content-Type header, which we know we cannot trust. Along the same lines, we know we cannot trust a file's extension. However, right now, if the browser doesn't provide a useful Content-Type, we don't check the extension either.

So the idea would be, until we can do #1838, to use the file extension to determine the mediatype, either always, or when we don't get a useful Content-Type from the browser.

+1 from customer

[ebruchez]

• implement
• tests
• backport to 2019.2.1 customer branch
• backport to 2018.2.4 customer branch

[ebruchez]

We produce a mediatype based on the file extension in those cases where the browser doesn't doesn't send the correct mediatype. This mediatype is stored, and used to validate the mediatype on the server when we use a "Supported Files Types" validation.

However, when using a "Supported Files Types" validation, we also output an accept attribute on the <input type="file"> element. I wondered if this would cause a problem.

With Chrome, Safari, and Firefox on Mac, at least, it seems that when the browser doesn't know the mediatype, it proposes all files in the file selector, which is good. This is the case with application/vnd.ms-outlook, for example

I was thinking that, if this was not the case with all browsers, we could also output an extension in the accept attribute. See this SO question.

For now, I am not sure we need to do anything given the above.

[avernet]

@ebruchez Is this new behavior documented? IMHO, this is also blog-worthy. (Should have a "blog-worthy" tag?)

[ebruchez]

Just now documented.

We have a list of possible blog posts in our recurring calendar entry. Not sure if a label is necessary?

[avernet]

👍 for the doc; and no need for a tag if we have a list somewhere.