Re: Auto-Download tags/function?

George Phillips <phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 19 May 1994 21:02:47 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <8318*phillips@cs.ubc.ca>
Errors-To: listmaster@www0.cern.ch
Reply-To: phillips@cs.ubc.ca
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: George Phillips <phillips@cs.ubc.ca>
To: Multiple recipients of list <www-talk@www0.cern.ch>
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:

	ftp://host.dom/a/directory;type=dir
	ftp://host.dom/text/file;type=ascii
	ftp://host.dom/binary/file;type=image

Or whatever.  For ***FTP*** URLs this is reasonable and extending
that syntax to something like

	ftp://host.dom/binary/file;type=image;content-type=image/gif

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.