Any way to get supported file extensions?

[cmeeren]

I have a file upload/download API where I am using ImageSharp for downscaling images to create thumbnails of uploaded images (the API supports non-image formats, too). Is there a way I can get a list of the supported file extensions, so that I know which files to process with ImageSharp and which not to?

[JimBobSquarePants]

File extensions should never be used as a means to determine a file type. There's nothing stopping anyone putting any extension on any file type which will cause ImageSharp to throw if a file cannot be decoded.

Rather, you should use Image.DetectFormat(Configuration, Stream)

If that returns null then you know the stream does not contain a supported image format. Remember to reset the stream position after calling this method for subsequent decoding and manipulation.

[cmeeren]

Are you not saving the correct content type when uploading the file to blob storage?

API clients/users POST files to my API, and they have to supply a filename, but I don't get a content-type. AFAIK for a general file upload API like this, the content type would just be a guess based on the extension anyway, but please let me know if I'm wrong and should indeed require clients to specify a content-type, not just a filename (with an extension).

When users download files from my API, I use Microsoft.AspNetCore.StaticFiles.FileExtensionContentTypeProvider to get a content type from the file extension.

the FileBufferingReadStream provided by ASP.NET Core is seekable.

I am using HttpRequest.Body (httpContext.Request.Body), which is just a Stream. I'm streaming directly from the client to the blob.

[antonfirsov]

I would suggest simply cacthing ImageFormatException with Image.Load(Async) to detect the case when the stream does not contain an image. OFC you can make a pre-filtering based on the extension but you shouldn't rely on that. I would handle the extension/mime mismatch and the exception with similar (or same) logic in your service.

@JimBobSquarePants anything against this?

[cmeeren]

@antonfirsov Thanks, that's in fact just what I'm doing (pre-filtering and then catching any exception - whether from ImageSharp or the blob storage - and serving the original, non-resized file in both cases).

[JimBobSquarePants]

@cmeeren

I am using HttpRequest.Body (httpContext.Request.Body), which is just a Stream. I'm streaming directly from the client to the blob.

It's never just a Stream, Stream is the abstract type. I'm really curious as to how you receive your binary content then because any upload is normally seekable due to that wrapper.

@antonfirsov Image.Load + catch requires the stream to be seekable since you cannot then reset the stream position to zero after internal copying to our decode stream if it is not.

Image.Load(nonSeekableStream);

nonSeekableStream.ReadByte() // -1

[cmeeren]

It's never just a Stream, Stream is the abstract type.

Sure, but the concrete implementation is an implementation detail subject to change (otherwise I assume they'd just return a more concrete type), so I can't depend on it.

I'm really curious as to how you receive your binary content then because any upload is normally seekable due to that wrapper.

It's not multipart or form-encoded or something like that, if that's what you're thinking of. The entire message body is the binary contents of the file, and the request must contain a Content-Disposition header with the filename.

I arrived at this solution after some research because I need to support large (~GB) files and thus very specifically wanted a solution that could stream files wherever I wanted (e.g. to DB, Azure Blob, or disk) without buffering in memory.

ASP.NET Core has helpers for reading multipart/form-encoded content, but as far as I could tell, everything there would buffer the entire request into memory.

Hence, I am using HttpContext.Request.Body, which is the Stream that reads the request body.

Note again that this is a stand-alone "REST" API, not a web app. (The file upload/download endpoints are not particularly REST-ish of course, but the rest of the API ecosystem is.)

(Side note: To further complicate matters, certain big files are likely to be uploaded multiple times by different users and require some expensive processing on our side, so we accept a checksum in the request that, if it matches a previously uploaded file, skips the upload entirely. Due to HTTP spec implementation reasons on the part of Kestrel and/or IIS, this means the request must be performed in a "dry-run" mode first without the body itself, because the body will be drained, i.e. the file "uploaded" from the user, whether or not the API reads the body. HTTP/2 was supposed to avoid that draining, but I haven't gotten it to work on Azure or IIS. Deduplicated files still look like "new" files to the user though, so we differentiate between physical and logical files internally in the API.)

[tocsoft]

You can get a list of all file extensions (with image decoders) registered against the configured image formats using this:

// For simple cases where you are not specifying a custom Configuration
SixLabors.ImageSharp.Configuration config = SixLabors.ImageSharp.Configuration.Default;

// if using IamgeSharp.Web you will want to resolve by getting a refernece to `ImageSharpMiddlewareOptions` 
//.from DI and the reading the Configuration property from it.

var allSupportedExtensions = config.ImageFormats
    .Where(x=> config.ImageFormatsManager.FindDecoder(x) != null) // we can decode this format (i.e. its not an encode only format)
    .SelectMany(x => x.FileExtensions);

[Susko3]

.Where(imageFormat => config.ImageFormatsManager.FindDecoder(imageFormat) != null)

In newer ImageSharp versions, ImageFormatsManager.FindDecoder() throws instead of returning null. Seems silly that client code should catch an exception to check whether a format is available for decoding. Is there a better way of checking available decoder formats? If not, do you think that adding a TryGet/TryFind-style function makes sense?

[JimBobSquarePants]

You are responsible for the configuration. You choose what formats are available.

[cmeeren]

I guess the question is, how can we programmatically get the formats/extensions supported by default?

[antonfirsov]

public static bool SupportsExtension(string extension) =>
    Configuration.Default.ImageFormats
    .SelectMany(f => f.FileExtensions)
    .Contains(extension, StringComparer.OrdinalIgnoreCase);

[JimBobSquarePants]

@Susko3 Just to clarify. None of the default formats will ever lack a decoder. The following will give you the full collection:

Configuration
.Default
.ImageFormats
.SelectMany(x => x.FileExtensions)
.ToArray();