Re: Auto-Download tags/function?
"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 19 May 1994 21:29:52 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405191925.AA11201@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
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
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
In message <8318*phillips@cs.ubc.ca>, George Phillips writes:
>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.
If the link specifies a content type that the browser is incapable
of presenting, firstly, this condition can be detected before the
browser goes to all the trouble to retrieve the document.
Secondly, it's reasonable for the browser to say
"This link says Postscript, but I don't grok postscript.
You want I should see if the doc is available in a
format that I do grok?"
It's even reasonable for the browser to assume the answer to
that question is yes (given suitable documentation, or better
yet -- a user settable preference).
What's not reasonable is:
* I am browsing some X-rays, and I want to include a reference
to one of them in my report. I write
HREF="http://med.com/xrays/100"
There are very subtle features in this x-ray, so I'd like
folks that follow this link to get _excactly_ the bits
I was looking at. Hmmm... I have no way of expressing
this. Oh well, maybe it'll just work...
* My colleage is browsing my report. His browser is set
to "lean and mean mode" -- it prefers low-res images where
available. He follows the link.
* A caching proxy server grabs the original 48MB tiff,
and decides it can reduce it to a 16K gif faster than
it can send the 48MB graphic over the wire.
* My colleage sees a low-res version of the x-ray, and
misses the subtle details, and gets NO WARNING that
the data has been compromised.
It's all about ensuring reliable communication with expressive
links and fault detection mechanisms.
> Such an extension may be acceptible if it means
>"image/gif is the preferred format if my browser understand it".
Yes, this is the idea, except that it's much more useful in
the case where the author and the reader are different parties,
i.e. in the case where you want to say "image/gif is the
preferred format if _your_ browser understands 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.
That's news to me! I read that support for text/plain and text/html
is required, but I have seen no HTTP (or any WWW technology) requirement
for support of application/octet-stream.
It's reasonable to expect most browsers to handle that type (except
"kiosk" style browsers, like the one you get when you telnet
to info.cern.ch, that have no disk space to write to), but I don't
think there are any specs that require it.
>But "http://host/file;content-type=application/postscript" may
>not always work out.
Yes, there are associated error conditions. But they are well
defined, and the increase in functionality merits the complication.
Dan