Re: Auto-Download tags/function? George Phillips <email@example.com>
Date: Thu, 19 May 1994 21:02:47 +0200
From: George Phillips <firstname.lastname@example.org>
To: Multiple recipients of list <email@example.com>
Subject: Re: Auto-Download tags/function?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Dan Connoly writes:
>All these ".dump", ".saveme" methods are fine if you own both ends of
>the link. But what if the file you're linking to is on somebody
>_else_'s FTP server? What if there's a report in postscript format,
>and the filename doesn't end in .ps? Without the ability to express
>the content type in the link, we're SOL.
Actually, the IETF "URL" working group has addressed an issue close
to yours for ftp: URLs. They wanted to be specific, when possible,
about what FTP transfer mode to use and the command to use (is the
remote thing a file or a directory). I may have the details wrong,
but the proposed solution was to add ";type=something" to the end
of the URL. So you might have:
Or whatever. For ***FTP*** URLs this is reasonable and extending
that syntax to something like
seems reasonable enough. I'm not so sure that dropping that syntax
onto HTTP URLs is a good idea. If I can follow a link with my browser
that will give me back something that my browser can't deal with, I
won't be happy. Such an extension may be acceptible if it means
"image/gif is the preferred format if my browser understand it".
That way, you could say "http://host/file;content-type=application/oct..."
and expect it to work since every browser can deal with that type.
But "http://host/file;content-type=application/postscript" may
not always work out.