[BUG] Improper Input Validation in CreateFilePart (MIME Type Bypass)

[Pietro-Salomone]

Bug Description

When using the method:

public static ChatMessageContentPart CreateFilePart(BinaryData fileBytes, string fileBytesMediaType, string filename)

I have encountered that passing fileBytes with a fileBytesMediaType different from "application/pdf" results in an HTTP 400 error.

Steps to Reproduce

1. Call CreateFilePart() for example with a PowerPoint file (.pptx) (works also with txt, docx...)
2. Set fileBytesMediaType to the correct MIME type: "application/vnd.openxmlformats-officedocument.presentationml.presentation"
3. Send the request

Actual Behavior

Receives HTTP 400 error with the following message:

HTTP 400 (invalid_request_error: invalid_value)
Parameter: messages[1].content[1].file.file_data

Invalid file data: 'messages[1].content[1].file.file_data'. Expected a base64-encoded data URL with an application/pdf MIME type (e.g. 'data:application/pdf;base64,SGVsbG8sIFdvcmxkIQ=='), but got unsupported MIME type 'application/vnd.openxmlformats-officedocument.presentationml.presentation'.

Workaround

Setting fileBytesMediaType to "application/pdf" for the same .pptx file allows the document to be processed successfully, despite the incorrect MIME type.

Code snippets

if (file.FileData != null && file.FileData.Length > 0)
{
	//set always to pdf
	file.ContentType = "application/pdf";
	var binaryData = new BinaryData(file.FileData);
	userContentParts.Add(ChatMessageContentPart.CreateFilePart(
			binaryData, file.ContentType, file.FileName));
}

Question

Is this intended behavior? The error message suggests only PDF files are supported.

OS

Windows

.NET version

.NET 8

Library version

OpenAI (2.2.0-beta.4)

[jsquire]

Hi @Pietro-Salomone. Thank you for reaching out and we regret that you're experiencing difficulties. The error that you're seeing is service behavior that the client has no insight into nor influence over. The HTTP 400 response seems to indicate that the service is only accepting application/pdf, but this is an implementation detail that the client cannot infer and cannot assume will not change in the future.

The service API docs (User message > content > File content part > file) does not specify constraints on the type of file, it defines file_data only as "The base64 encoded file data, used when passing the file to the model as a 'string.'" and the REST API spec likewise defines it only as string.

The maintainers of the OpenAI client library are unable to provide an answer on whether this is an intentional limitation or a service issue. Unfortunately, OpenAI does not offer service support from this repository. The most reliable and direct way to get support is by reaching out to the OpenAI Support Team. You can either email support@openai.com or start a new chat session via the Help Center. The OpenAI support team is available 24/7 and is equipped to assist with the full range of requests.

[Pietro-Salomone]

Hi @jsquire ,

Thank you for the detailed explanation.
I appreciate you clarifying that this is a service-level behavior rather than a client library limitation.
I'll reach out to the OpenAI Support Team as you suggested.

Best regards.