[6548] in www-talk@info.cern.ch
Re: An MGET proposal for HTTP
daemon@ATHENA.MIT.EDU (Marc VanHeyningen)
Thu Nov 3 08:47:49 1994
Date: Thu, 3 Nov 1994 14:46:27 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
> OK, yuk. IMG (and FIG) actually serve as useful hints to the
> client as to what sort of thing a link is to. That is what I was
> thinking of, although yes of course you are right, in general there is
> no telling what is sensible. If I have a link to a paper abstract in
> html, an d then later a link to the Postscript of the full paper, the
> client cannot know to treat these requests any differently.
Correct; in general, there are only two different kinds of requests:
inline images and everything else.
> Anyway, in the general case, yes perhaps we need an attribute for
> anchor elements that tells the browser precisely what class of object
> it is. Then we need a way for a browser to match up classes of object
> with MIME types read from the mailcaps so it sends appropriate ones.
> Scope there for some hot discussion on what the classes of object are,
> I suspect.
There is such a provision suggested in HTML 3.0; the "type" parameter
of anchors suggests what the content-type of the object referenced, but
it's advisory only and non-authoritative. The client should not use it to
tailor the Accept: fields it sends.
> But at the moment (re the other current thread about the online
> newspaper) if a client asks for newspaper.htl with accept text/html and
> image/gif, sending a big gif of the page is not actually wrong.
> Undesirable, but it conforms with what the client said it would accept.
This is a function of content-type negotiation; it is generally
not possible to losslessly convert HTML to GIF. But, yes, the spec allows
the server to decide, based on the information given to it by the client,
whatever content-type it considers most appropriate. That's the point.
Are you saying the spec should prohibit this?
