Images are saved as application/octet-stream instead of correct content type

[2shrestha22]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server and the Parse Flutter SDK.

Issue Description

When we save files with ParseXFile(XFile.fromData(bytes), name: 'myimage.jpg'), it is sent with content-type: [application/octet-stream] and the SDK is not able to get correct content type.

Steps to reproduce

Upload an image and see the http request, also preview in parse dashboard. When you open the image link it starts to download immediately instead of previews it. Because it is saved with wrong content type.

Actual Outcome

Images are saved with content-type: [application/octet-stream].

Expected Outcome

Images should be saved with correct content type, when file name is provided.

Environment

Parse Flutter SDK

• SDK version: 8.0.1
• Flutter version: all
• Dart version: all
• Operating system version: all

Server

• Parse Server version: all

Logs

[parse-github-assistant]

🚀 Thanks for opening this issue!

ℹ️ You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[mtrezza]

Is this a SDK or server issue?

[2shrestha22]

SDK

[2shrestha22]

For workaround we can manually set the mimetype in XFile constructor.

[mtrezza]

I want to confirm that this is an SDK issue, not a server issue. I understand the issue is about downloading a file from Parse Server. Parse Server already identifies the mime type from the file extension in FilesController.js:

  async createFile(config, filename, data, contentType, options) {
    const extname = path.extname(filename);

    const hasExtension = extname.length > 0;
    const mime = (await import('mime')).default
    if (!hasExtension && contentType && mime.getExtension(contentType)) {
      filename = filename + '.' + mime.getExtension(contentType);
    } else if (hasExtension && !contentType) {
      contentType = mime.getType(filename);
    }

    if (!this.options.preserveFileName) {
      filename = randomHexString(32) + '_' + filename;
    }

    const location = await this.adapter.getFileLocation(config, filename);
    await this.adapter.createFile(filename, data, contentType, options);
    return {
      url: location,
      name: filename,
    }
  }

When we save files with ParseXFile(XFile.fromData(bytes), name: 'myimage.jpg'), it is sent with content-type: [application/octet-stream] and the SDK is not able to get correct content type.

In this case the file extension doesn't match the SDK's default content type, so maybe the solution is to not set any content type by default, because the server will infer the content type from the type extension anyway. Or only set the content type application/octet-stream if no file extension is set. I'd suggest to align with how the JS SDK behaves.

All these changes would of course be breaking, so we'd need to release a new major version of the SDK.

[mtrezza]

@coderabbitai Investigate how the Parse JS SDK handles this: whether it sets a content-type for file upload, or whether it leave this all to the server.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Clone Parse JS SDK and search for file upload logic
cd /tmp
git clone https://github.com/parse-community/Parse-SDK-JS.git
cd Parse-SDK-JS

# Find file-related source files
echo "=== Finding file-related source files ==="
fd -e js -e ts | grep -i file | head -20

# Search for ParseFile class implementation
echo -e "\n=== Searching for ParseFile class ==="
rg -n "class ParseFile" --type js --type ts

# Search for content-type handling in file uploads
echo -e "\n=== Searching for content-type in file context ==="
rg -n -C5 "contentType|content-type|mimeType|mime" --type js --type ts | grep -A5 -B5 -i "file"

Length of output: 8860

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Get the main ParseFile implementation
echo "=== ParseFile.js content ==="
cat src/ParseFile.js

Length of output: 77

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Search for file upload/save methods
echo "=== Searching for file save/upload methods ==="
rg -n -A10 "\.save\(" src/ParseFile.js

# Search for how data is sent to server
echo -e "\n=== Searching for file data transmission ==="
rg -n -C8 "RESTController|fetch|upload" src/ParseFile.js

Length of output: 206

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check RESTController for file upload handling
echo "=== Finding RESTController ==="
fd RESTController

echo -e "\n=== Checking RESTController file upload handling ==="
cat src/RESTController.js | head -200

Length of output: 223

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Search for how files are uploaded in RESTController
echo "=== Searching for file upload in RESTController ==="
rg -n -C10 "files/|/files" src/RESTController.js

# Look at the full ajax/request method
echo -e "\n=== Looking for request/ajax methods ==="
rg -n -A15 "function ajax|const ajax" src/RESTController.js

Length of output: 217

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Read the ParseFile.ts implementation
echo "=== ParseFile.ts content (part 1 - lines 1-150) ==="
head -150 src/ParseFile.ts

echo -e "\n=== ParseFile.ts content (part 2 - lines 151-300) ==="
sed -n '151,300p' src/ParseFile.ts

echo -e "\n=== ParseFile.ts content (part 3 - lines 301-450) ==="
sed -n '301,450p' src/ParseFile.ts

echo -e "\n=== ParseFile.ts content (part 4 - lines 451-end) ==="
tail -n +451 src/ParseFile.ts

Length of output: 17352

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Search for saveFile and saveBase64 implementations in RESTController
echo "=== Searching for file upload methods in RESTController.ts ==="
rg -n -A30 "saveFile|saveBase64" src/RESTController.ts

Length of output: 62

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Look at the file controller implementations
echo "=== Looking for FileController ==="
rg -n -B5 -A50 "const FileController" src/ParseFile.ts

Length of output: 34

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check how FormData or file upload is handled
echo "=== Searching for FormData or file upload in RESTController ==="
rg -n -C10 "FormData|multipart" src/RESTController.ts

echo -e "\n=== Searching for Content-Type header setting ==="
rg -n -C8 "'Content-Type'|\"Content-Type\"|Content-Type:" src/RESTController.ts

Length of output: 810

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check how the constructor handles the type parameter
echo "=== Constructor type parameter handling ==="
sed -n '100,145p' src/ParseFile.ts

# Look specifically at how specifiedType is used
echo -e "\n=== How specifiedType is initialized and used ==="
rg -n "specifiedType" src/ParseFile.ts

Length of output: 1719

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check test files to see examples of how ParseFile is created with/without type
echo "=== Test examples of ParseFile creation ==="
rg -n -B2 -A2 "new ParseFile" src/__tests__/ParseFile-test.js | head -80

Length of output: 2995

---

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check the TypeScript types to understand the type parameter better
echo "=== ParseFile type definitions ==="
cat types/ParseFile.d.ts

Length of output: 6985

---

@mtrezza I've investigated the Parse JS SDK and found how it handles content-type for file uploads:

Key Findings

The Parse JS SDK does NOT set a default content-type like application/octet-stream. Instead, it only includes a _ContentType field in the upload payload when explicitly provided.

How it works:

1. Constructor behavior (line 100 of ParseFile.ts):

   const specifiedType = type || '';

   If no type parameter is provided, it defaults to an empty string.

2. saveBase64 method (lines 467-482 of ParseFile.ts):

   saveBase64: function (name: string, source: FileSource, options: FileSaveOptions = {}) {
     const data = {
       base64: source.base64,
       fileData: {
         metadata: { ...options.metadata },
         tags: { ...options.tags },
       },
     };
     if (source.type) {  // Only sets _ContentType if truthy
       data._ContentType = source.type;
     }
     const path = 'files/' + name;
     return CoreManager.getRESTController().request('POST', path, data, options);
   }

3. Critical behavior: When source.type is an empty string or undefined, the _ContentType field is not included in the request payload at all.

4. saveFile method (line 463): For Blob/File objects, it attempts to use the type from the Blob:

   type: source.type || (source.file ? source.file.type : undefined)

Documentation

The constructor's JSDoc explicitly states:

"Optional Content-Type header to use for the file. If this is omitted, the content type will be inferred from the name's extension."

Conclusion

The JS SDK's approach is to:

• Not send any content-type to the server when none is explicitly provided or available from a Blob
• Rely entirely on Parse Server to infer the content-type from the file extension (as shown in the FilesController.js code you referenced)

This confirms your suspicion that the Flutter SDK should align with this behavior and avoid setting application/octet-stream as a default, allowing the server to infer the correct content-type from the file extension instead.

[mtrezza]

@coderabbitai does the JS not set a default content type, even if the file has no extension?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Search for any logic that checks for file extensions in ParseFile
echo "=== Searching for extension checking logic ==="
rg -n -C8 "extension|extname|\.split.*\." src/ParseFile.ts

# Check if there's any default content-type logic based on filename
echo -e "\n=== Searching for default content-type logic ==="
rg -n -C8 "application/octet-stream|default.*type|no extension" src/ParseFile.ts

# Look at the save method more carefully
echo -e "\n=== Reviewing save method implementation ==="
sed -n '290,350p' src/ParseFile.ts

# Check if there's any filename processing that affects content-type
echo -e "\n=== Searching for filename processing ==="
rg -n -C5 "this\._name|filename" src/ParseFile.ts | head -60

Length of output: 484

---

🏁 Script executed:

#!/bin/bash
# Clone Parse JS SDK again
cd /tmp
rm -rf Parse-SDK-JS
git clone https://github.com/parse-community/Parse-SDK-JS.git
cd Parse-SDK-JS

# Search for any logic that checks for file extensions in ParseFile
echo "=== Searching for extension checking logic ==="
rg -n -C8 "extension|extname" src/ParseFile.ts

# Check if there's any default content-type logic based on filename
echo -e "\n=== Searching for default content-type being set ==="
rg -n -C8 "application/octet-stream" src/ParseFile.ts

# Look at the complete save method and any type handling
echo -e "\n=== Looking at save method and type handling ==="
sed -n '280,360p' src/ParseFile.ts

# Check constructor again for any default type logic
echo -e "\n=== Constructor type initialization ==="
sed -n '90,150p' src/ParseFile.ts

Length of output: 5684

---

@mtrezza Correct, the Parse JS SDK does NOT set a content-type even when the file has no extension.

Evidence from the code:

1. No extension checking logic: There is no code in ParseFile.ts that checks whether a filename has an extension or not.

2. Empty string is falsy: When no type is provided to the constructor, it sets:

   const specifiedType = type || '';  // empty string

3. Conditional content-type setting (from saveBase64 method shown in previous investigation):

   if (source.type) {  // empty string is falsy, so this block is skipped
     data._ContentType = source.type;
   }

4. Result: When source.type is an empty string (the default), the _ContentType field is completely omitted from the request payload sent to Parse Server.

Behavior summary:

• File with extension, no type provided: No _ContentType sent → Server infers from extension
• File without extension, no type provided: No _ContentType sent → Server receives no content-type
• File with/without extension, type provided: _ContentType sent with provided value

The JS SDK's documentation states: "the content type will be inferred from the name's extension" but this inference happens server-side, not in the SDK. The SDK itself never sets a default like application/octet-stream.

For files without extensions and no explicit type, Parse Server would receive neither a content-type nor be able to infer one from the filename, leaving it up to the file adapter's default behavior.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
cd /tmp/Parse-SDK-JS

# Check if there's any logic that detects or handles files without extensions
echo "=== Searching for extension detection logic in ParseFile ==="
rg -n -C8 "extname|extension|hasExtension|\\.split\(" src/ParseFile.ts

# Check if there's any default content-type logic for files without extensions
echo -e "\n=== Searching for default content-type logic ==="
rg -n -C5 "default.*type|fallback.*type|application/octet" src/ParseFile.ts

# Look at the full save/upload flow to see if defaults are set anywhere
echo -e "\n=== Checking the save method flow ==="
sed -n '200,300p' src/ParseFile.ts

Length of output: 391

---

🏁 Script executed:

#!/bin/bash
# Clone Parse JS SDK fresh
rm -rf /tmp/Parse-SDK-JS
cd /tmp
git clone --depth 1 https://github.com/parse-community/Parse-SDK-JS.git
cd Parse-SDK-JS

# Check if there's any logic that detects or handles files without extensions
echo "=== Searching for extension detection logic in ParseFile ==="
rg -n -C8 "extname|extension|hasExtension" src/ParseFile.ts

# Check if there's any default content-type logic for files without extensions
echo -e "\n=== Searching for default or fallback content-type logic ==="
rg -n -C5 "default.*type|fallback.*type|application/octet|octet-stream" src/ParseFile.ts

# Look at the constructor again to confirm the default behavior
echo -e "\n=== Constructor type parameter initialization ==="
sed -n '90,150p' src/ParseFile.ts

# Check the saveBase64 method again to confirm conditional logic
echo -e "\n=== saveBase64 method content-type handling ==="
sed -n '460,490p' src/ParseFile.ts

Length of output: 4436

---

@mtrezza No, the JS SDK does not set a default content type for files without extensions. Here's what I found:

Key Behavior:

1. Default is an empty string: Line 100 shows const specifiedType = type || '';

2. Empty type = no _ContentType field sent: In the saveBase64 method (lines 476-481), the content-type is only included if truthy:

   if (source.type) {
     data._ContentType = source.type;
   }

   Since an empty string is falsy in JavaScript, no _ContentType field is sent to the server at all.

3. No extension detection logic: There's no code in ParseFile.ts that checks whether a filename has an extension or applies special handling for extension-less files.

One Exception:

There is one special case for Base64 data URLs (lines 130-139). When you pass data in the format data:image/png;base64,..., it tries to parse the MIME type from the data URL itself, and only falls back to 'text/plain' if parsing fails:

const dataType =
  specifiedType ||
  (data as Base64).base64.split(';').slice(0, 1)[0].split(':').slice(1, 2)[0] ||
  'text/plain';

But for regular file uploads (byte arrays, Blobs, URIs) without extensions and without an explicit type parameter, the JS SDK sends no content-type to the server, leaving it entirely up to Parse Server. Without a file extension, the server presumably cannot infer the type either, which could result in the server's own default behavior.

[2shrestha22]

We are setting default content type as a fallback and not checking the file name.

[mtrezza]

There is not default content type in JS SDK, so we'll align with that. The server infers the content type from the file extension. Could you please take a look at https://github.com/parse-community/Parse-SDK-Flutter/pull/1048/files and let me know if that works?