Thank you for your report and suggestions.

Current behavior:
Modern browsers (such as Chrome and Firefox) correctly recognize and provide the MIME type for .zip (application/x-zip-compressed) and .rar (application/x-rar-compressed or application/x-compressed) files. In these cases, File.ContentType is set as expected on both the client and server.

For extensions like .sql, .msg, .rpt, and .zipx, browsers do not provide a MIME type (file.type is an empty string on the client), even if the correct MIME type is registered in the server’s web.config or IIS. As a result, File.ContentType is null or "application/octet-stream" on the server.

Explanation:
The browser determines the MIME type based on its internal mapping. If the extension is not recognized, it does not send a MIME type, and the server cannot infer it from the HTTP request alone.

Registering the MIME type in web.config or IIS helps with static file serving, but does not affect the value sent by the browser during file upload.

  <staticContent>
    <mimeMap fileExtension=".sql" mimeType="text/plain" />
    <mimeMap fileExtension=".rar" mimeType="application/x-rar-compressed" />
    <mimeMap fileExtension=".msg" mimeType="application/vnd.ms-outlook" />
  </staticContent>

In our case, .zip, .rar and .msg MIME types were already present in the MimeTypes.Types dictionary of Telerik.Web.UI\Common\MimeTypes.cs. The only new entry added was for .sql, ensuring that even if the browser does not provide a MIME type, the server logic can assign the correct one based on the file extension.