The previous implementation made an incorrect assumption about download
behaviours. For file types electron understands, it would display rather
than trigger the special download handling.
So we force download handling by setting attachment disposition.
However, we still no to be able to not trigger native opening for the
outputs and feedback zip downloads.
So, we explicitly signal that native app opening is allowed in
/contents responses, but not the zip/feedback responses.
We do this via a header, whoever there's a wrinkle. Electron's
DownloadItem API does support accessing arbitrary headers. So, instead,
we add this explicit marker as an additonal native=true field in the
Content-Disposition header, which we can access via DownloadItem.
This is a little unusual, but AFAICT is support by the spec.
The previous implementation made an incorrect assumption about download behaviours. For file types electron understands, it would display rather than trigger the special download handling.
So we force download handling by setting
attachmentdisposition. However, we still no to be able to not trigger native opening for the outputs and feedback zip downloads.So, we explicitly signal that native app opening is allowed in
/contentsresponses, but not the zip/feedback responses.We do this via a header, whoever there's a wrinkle. Electron's DownloadItem API does support accessing arbitrary headers. So, instead, we add this explicit marker as an additonal
native=truefield in the Content-Disposition header, which we can access via DownloadItem.This is a little unusual, but AFAICT is support by the spec.
Fixes #206