Re: Auto-Download tags/function?

George Phillips <>
Date: Thu, 19 May 1994 21:02:47 +0200
Message-id: <8318*>
Precedence: bulk
From: George Phillips <>
To: Multiple recipients of list <>
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.