cant view .sc / .scd files

[catfact]

this is a weird one, i dont remember seeing it before?

seleting a .sc file in maiden makes the UI show the "thinking" animation for a long moment, then displays a blank editor:

(the file exists:)

[ngwese]

If I had to guess this might have been broken around the time audio file preview was added.

[ngwese]

Super weird. This seems to only happen on the latest image. The same build on an older image or running remotely (and accessing norns via sshfs) does not exhibit the problem.

[ngwese]

The backend is serving the file in full. On older images (or macOS) the reported content type for the file is:

Content-Type: text/plain; charset=utf-8

...but when running on the newer bullseye based OS the content-type is reported as:

Content-Type: application/vnd.ibm.secure-container

[ngwese]

The root cause is still not clear but the problem seems to be that http.DetectContetType(...) (https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/net/http/sniff.go;l=21) is producing a different result on the new OS. The maiden backend is using the gin framework's context.File function to return the file contents. That function in turn is a minimal wrapper around http.ServerFile which itself leans on http.DeteContentType to set the header.

[ngwese]

The root cause is that if a file path is supplied to http.ServeFile and the extension on that file appears in /etc/mime.types then the mime type entry is used to set the Content-Type for the request. The previous debian stretch based image did not have an entry for sc but the bullseye image contains an entry for sc which maps it to application/vnd.ibm.secure-container. The net result is that the editor doesn't believe the file is text a falls back to (confusingly) displaying an empty editor.

[ngwese]

Unfortunately there is no way to override the default behavior of using the extension to dictate the mime type other than hard coding knowledge of .sc files into maiden itself.

fixed as of c516419ebbaf6c4c0ea4db207bfb98efb0c62af5