SODA, half-client

[Markus Demleitner]

Hi James,

On Mon, Apr 04, 2016 at 09:54:27PM +0000, James.Dempsey at csiro.au wrote:
[SODA endpoint not assigning names to files returned]
> The main reason is for the convenience of users. In the services I
> have set up I have inevitably been requested to provide friendly,
> unique, names for downloads. The extension is helpful for windows
> users where it is used to determine file launch actions. Also,
> consider this not in the context of doing a cutout now and using
> it, but rather in the context of coming back in a week and seeing
> dlget, dlget-1, dlget-2 etc and wondering which is which.
> 
> The name currently comes from the url, but you can specify the file
> name as part of the download stream header, which will split it
> from the url. I definitely agree that it is best not to force the
> url to carry the filename and extension.

So, in principle I agree that it's a good idea to have
content-disposition headers, and my SODA service had them until I
started to pull JPEGs and PNGs from them -- people wanted them to be
displayed in their web browsers rather than save them.  Rather than
switching behaviour based on -- hm, media type, perhaps, I switched
the whole thing off hoping that further complaints might give me more
ideas what to do.

While my hope of course is that we'll have good SODA clients that
people  will use instead of web browsers and this whole problem goes
away, I suppose a piece "good practices" for content-disposition
would be nice material either for a non-normative appendix to the
spec or an implementation note.

Since a constant "result.fits" (which I used when I still had
content-disposition:attacment) would only be marginally better than
dlget after what you write: How do you generate your names?  

Cheers,

         Markus