Re: An MGET proposal for HTTP

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Thu, 03 Nov 1994 08:25:08 -0500


> 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?