Background

Within the build output of any flutter app, there exists a unique file, the asset manifest (currently named AssetManifest.smcbin). This file contains metadata about assets that are available to the app at runtime. In particular, it provides the framework a cross-platform means to discover higher-resolution variants of image assets.

#122505 changed the extension and underlying format of the file. Before this, it was JSON (AssetManifest.json). This changed the file to be a serialized binary object (AssetManifest.bin, encoded using StandardMessageCodec). A follow-up hotfix changed the filename again to AssetManifest.smcbin, which is the current name as of writing.

Issue

Ideally, changing the extension (or any other aspect) of AssetManifest.smcbin should not impact customers, as this file is a framework-internal implementation detail. However, customers deploying flutter web apps have been impacted with vague, frustrating issues. Here are known examples, with some affecting several customers:

• Asset images are not loading (with Internet Download Manager installed on Microsoft Windows) #124883
  • This is what prompted the change from AssetManifest.bin to AssetManifest.smcbin, which may have been a mistake in hindsight. See the following issues in this list.
• Unable to load assets in flutter web: Flutter Web engine failed to fetch "assets/AssetManifest.smcbin" #128230
  • By default, some (most?) production IIS web servers are configured to not serve files for which it does not recognize the extension. Clients requesting these files will get a vague 404 response.
• Column header icons not displaying in cocoon #127038
  • Similar to the previous issue. To my knowledge, the web server did not know what to use for the content-type header, so it wouldn't serve the file.

The main purpose of this issue is to document this (to be added as a code comment) and raise awareness of this issue, as it could be a problem for other features that rely on requesting files with uncommon extensions (hopefully none).

Takeaway questions: is there a way for us to improve this situation for customers? Is there some sort of way to, in the build output, hint to web servers that this file is safe to serve to clients? Can we make these type of issues easier to catch and debug? Is there some other , well-known, file extension we could use that would be safer (such as .bin, at the risk of reintroducing #124883).