"Open in browser" on dataset_description.json results in Download request

[yarikoptic]

on https://dandiarchive.org/dandiset/000108/draft/files?location= clicking on the .json file which could be easily visualized by browser leads to download.

Chromium	128.0.6613.113 (Official Build) built on Debian GNU/Linux trixie/sid (64-bit) 
Revision	9597ae93a15d4d03089b4e9997b1072228baa9ad-refs/branch-heads/6613@{#1429}
OS	Linux
JavaScript	V8 12.8.374.24
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Command Line	/usr/lib/chromium/chromium --show-component-extension-options --enable-gpu-rasterization --no-default-browser-check --disable-pings --media-router=0 --enable-remote-extensions --load-extension --flag-switches-begin --disable-quic --flag-switches-end
Executable Path	/usr/lib/chromium/chromium
Profile Path	/home/yoh/.config/chromium/Default
Variations Seed Type	Null

References:

• add context viewer support for other file types #742

[waxlamp]

I am not sure there's anything for us to do here. For me:

• in Brave, the browser just downloads the file.
• in Firefox, I get a dialog asking me what to do; if I select "open in Firefox" then indeed my browser renders the JSON file with some kind of (built in?) plugin for JSON files. (It feels like there is perhaps a Firefox setting that would do this automatically for JSON files.)

In other words, this seems like something the user would have to configure (through plugins and settings) in order to add browser-level handling for JSON files.

The quantum leap would be for us to create our own in-DANDI JSON viewer but that seems very out of scope. Let me know what you think.

[yarikoptic]

TL;DR: it is due to encodingFormat we (dandi-cli or user via API) uploaded in metadata for the assets. In dandi-cli we rely now on https://docs.python.org/3/library/mimetypes.html to guess and provide mime type within encodingFormat. In newer dandisets all is good for those .json files: e.g. going to https://dandiarchive.org/dandiset/000874/draft/files?location= I can view those jsons file and in metadata record encodingFormat says json. So the question now on what to do to fixup metadata records for other jsons already in the archive? e.g. could a simple script be written which goes and fixups all metadata records where path points to .json file and has encodingFormat that application/octet-stream?

or could/should we provide in-code fixup... faster to be done than said:

• Provide workaround to specify "correct" content_type for JSON files in "inline" mode #2031

some exploration

so in Brave it prompts for download instead of just showing the file. Ideally it would just open/show that .json. I don't know why it doesn't -- that is something to investigate and possibly address... may be it is because of redirected to URL does not say that it is context type json but rather

Location: https://dandiarchive.s3.amazonaws.com/blobs/c07/71a/c0771a4f-3483-47e7-821e-b28ac8df46a5?response-content-disposition=inline%3B%20filename%3D%22dataset_description.json%22&response-content-type=application%2Foctet-stream&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAUBRWC5GAEKH3223E%2F20240920%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20240920T151948Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=b2a5377b279d44b376207462754867badcb790a9e6ddd6985adb608d104e78a0 [following]
--2024-09-20 11:19:48--  https://dandiarchive.s3.amazonaws.com/blobs/c07/71a/c0771a4f-3483-47e7-821e-b28ac8df46a5?response-content-disposition=inline%3B%20filename%3D%22dataset_description.json%22&response-content-type=application%2Foctet-stream&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAUBRWC5GAEKH3223E%2F20240920%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20240920T151948Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=b2a5377b279d44b376207462754867badcb790a9e6ddd6985adb608d104e78a0
Resolving dandiarchive.s3.amazonaws.com (dandiarchive.s3.amazonaws.com)... 52.219.179.20, 52.219.93.204, 3.5.132.189, ...
Connecting to dandiarchive.s3.amazonaws.com (dandiarchive.s3.amazonaws.com)|52.219.179.20|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  x-amz-id-2: CC5dV7aOm+GVdN1jadRHEU902hZzJNlY/g0vBCPDbUtY87z67qZAcGT0A256KnMzNfvaBR13z1o=
  x-amz-request-id: QCXQ2C47GBHMBAZV
  Date: Fri, 20 Sep 2024 15:19:49 GMT
  Last-Modified: Tue, 01 Jun 2021 18:15:20 GMT
  ETag: "f4a034fbf965f76828fa027c29860bc0-1"
  x-amz-version-id: nOp0gS1O6evD3TfRPAr5IV2Htf.voloo
  Content-Disposition: inline; filename="dataset_description.json"
  Accept-Ranges: bytes
  Content-Type: application/octet-stream
  Server: AmazonS3
  Content-Length: 71
Length: 71 [application/octet-stream]

I felt we had related issue and the closest I found was

• Extend Zarr entry upload procedure to support client-assigned Content-Types #1870

and apparently that is the encodingType we provide in that json metadata if we look at it : https://api.dandiarchive.org/api/dandisets/000108/versions/draft/assets/2847011b-f9fb-4933-a6b5-1641e0c1886b/

[waxlamp]

So the question now on what to do to fixup metadata records for other jsons already in the archive? e.g. could a simple script be written which goes and fixups all metadata records where path points to .json file and has encodingFormat that application/octet-stream?

I think this is the way. Let me look into it.

[waxlamp]

@yarikoptic I think this is now fixed (the example in the issue description now properly renders the JSON content in my browser).

I'll close this issue but please re-open if there are lingering issues.