Content sniffing should be used on text files to determine media type

Issues
1

Issue Description

Markdown files uploaded using WebDAV have a media type of inode/directory, instead of text/markdown.

When they are then accessed using JMAP they have media type of application/octet-stream, which is supposed to mean generic binary data.

Expected Behavior

A Markdown file should have a media type of text/markdown. This should either be inferred from the file name extension, if present, or from content sniffing.

Reproduction Steps

  1. Connect to the Stalwart WebDAV server using the Add Network Drive command in the desktop file manager.
  2. Drag and drop example.md (any Markdown file) into the remote Stalwart folder.
  3. Use the Show Details command in the file manager to see the media type. It shows inode/directory when it should say text/markdown.

Do the same with another WebDAV server (e.g. Synology), and the media type is correctly shown as text/markdown.

Connect to Stalwart via JMAP and use FileNode/get to ask for all files. In the response, example.md has type set to application/octet-stream instead of text/markdown.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Operating system: Pop!_OS 24.04 LTS
File manager: COSMIC Files

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Let me look into how Stalwart handles media types and content sniffing for WebDAV uploads.

This gives a clear picture of what is happening. Let me check the JMAP file handling for the application/octet-stream fallback as well.

3

What is happening is that the client (COSMIC Files) is sending Content-Type: inode/directory on the upload, and the server stores whatever the client sends without validating or inferring anything, so that bogus type sticks. We do not currently do extension-based detection or content sniffing for uploads at all. This should be filed as an enhancement request under the Ideas category.

4

Thanks. I’ve filed a bug with COSMIC Files.