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?