How do I supply `Files.contentType`?

[Omar Abdelkader]

How can I provide a value for my file's content type to the partitioning API?

I noticed that the code in unstructured-api determines how to partition each file using the content_type attribute attached to the FastAPI UploadFile. If one is not provided, it tries to infer the file type using the filename extension.

My file names are arbitrary UUIDs (no filename extension) so when I try to partition them I get this error

{"detail":"File type None is not supported."}

I would like to manually provide a value for UploadFile.content_type to avoid the fallback behavior but I don't see a way to do that using the JS client. Can we modify the Files definition to include an optional value for contentType, which I presume would be used in the unstructured-api code and result in skipping the fallback path?

export declare class Files extends SpeakeasyBase {
    content: Uint8Array;
    fileName: string;
    // PROPOSING WE ADD THE FOLLOWING LINE
    contentType?: string;
}

[Austin Walker]

Hi there, apologies for the delay. This is certainly something that should be in the client. I can do some digging and get back to you soon. We're also planning to improve the content type checking on the server side in the near term.

[Omar Abdelkader]

Hi @awalker4! Do you have any updates on this front? We'd like to upgrade to the new version of the JS client but we get the infamous {"detail":"File type None is not supported."} error when we try provide to provide a Blob type for the files argument. Unfortunately, when providing a Blob, you can no longer supply the fileName

[Austin Walker]

Hi Omar, sorry for the delays! We still need to get content_type in as a client param, and I'd like get around to that this week. As a workaround, the latest client does still take the files object from before, so you can set the filename. Check out the Typescript tab in the docs here. Let me know if this is sufficient for now, or if you're blocked on needing the content type.

Separately, I have an internal ticket to improve server side file handling. We can address the filetype None issue by actually inspecting the file and not just keying off of the extension.

[Omar Abdelkader]

No problem! Thanks for the quick response! Yes, once we upgrade we can continue to provide the Files object but we'd love to start using the Blob variant to avoid loading the entire file into memory at once.

For now, we've decided to stay on the older client version because we started running into fetch timeout issues at the 5 minute mark and I believe this issue is related nodejs/node#46375

[Ali Moezzi]

Also when supplying files: new Blob([data], { type: file.mimetype }), the splitPdfPage: true doesn't work and client raises Given file is not a PDF. Continuing without splitting.

[santy]

@alimoezzi

You can do this

const blob = await openAsBlob('path/to/filename.pdf');
const name = 'filename.pdf';
const file = new File([blob], name);

[Austin Walker]

Hi all, we've merged a fix for the API that removes the naive extension check and does an actual filetype detection. This will get rid of the Filetype None is not supported errors and should cover most of the cases where you'd need to explicitly send a content type. This is deployed in our hosted serverless and free tier APIs.

[Austin Walker]

We've added the contentType parameter to the SDK, to coincide with the new API param here. In addition to the better filetype checking, this issue should be resolved. Apologies for the very long turnaround time on this :/

@alimoezzi I created #100 for the pdf page splitting bug.