Inquiries about assets

Support
1

I have…

  • Read the following guideline: Troubleshooting and Support | Squidex. I understand that my support request might get deleted if I do not follow the guideline.
  • Used code blocks with ``` to format my code examples like JSON or logs properly.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Environment

  • Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: 7.21.1

Browser:

  • Chrome (desktop)

Others:

  1. etag header
    https://cloud.squidex.io/api/assets/8b381f48-69af-40d1-baff-9d1fb9776f8d
    Why is the etag header response coming back as 0?
**content-length**: 8130292
**content-type**: application/octet-stream
**date**: Mon, 01 Dec 2025 12:25:26 GMT
**accept-ranges**: bytes
**cache-control**: public,max-age=60
**etag**: 0
**vary**: Auth-State
**content-security-policy**: script-src 'none'
**content-disposition**: inline; filename="@BAKE.glb"; filename*=UTF-8''%40BAKE.glb
  1. Upload the asset and return the content-type as desired.
    When uploading assets, I’d like to receive a content-type response for a specific file.
    I need to determine the content-type to respond with when uploading an asset.
    Is there a way to solve this problem?
    For non-standard asset files, such as gltf or glb,
    the limitation is that the file is limited to application/octet-stream.
    The gltf file expects a response of model/gltf+json, and the glb file expects a response of model/gltf-binary.
2

I’ve confirmed that etag is processed based on version.
Is there a way to modify the content-type at the extension middleware level?

I wanted to test whether processing was possible at the Asset Script level, but
In the On Premise environment, typing in the AssetScripts code editor is not possible and a tooltip issue with Editing is disabled occurs.

3

At the script level, the mimeType can be changed or
I don’t think this problem can be solved other than the possibility of hooking and modifying DelegateAssetFile in AssetFileResolver when uploading.

4

The content-type is determined at upload time. So if you put in a pdf you get out an pdf. There is no way to change that.

5

When using API, it can be specified in multi-part, but when uploading in Web UI, form-upload is set as default, so it is default specified as octet-stream.

In this case, it can be solved by forking and modifying the frontend source code. However, when requesting asset get, I tried to receive it by looking at the fileName in the script query and modifying the mimetype, but it did not work.

For example, when processing a gltf file based on the asset API, it is processed correctly by specifying the content-type.

Internal workers use web UI, so they are fixed and uploaded as octet-stream.

6

Thats 100% not true. The browser defines the content type based on the file extension. When you use the API you have to define the correct content type.

7

Yes, that’s right. Some sentences may have been misrepresented by the translator.

The most realistic alternative would be to look at the fileName through query hooking in AssetScript, change the mimeType, and download it as a header. Is this a possible scenario?

There is a problem with these 3D-like assets that must be specified because the browser does not know the mime-type.

It seems that the problem will be solved if the mimeType is reflected in create/update in AssetScript.

image
image3164×1236 426 KB