> Neither text/html nor text/plain is necessary - if no Accept: header
> line is present they are taken as default values.
Fine.
> One question: how do you want the client to know what is
> `sensible' for a specific request? The only way I can think of
> is the OBNOXIOUS peeking at the file extension.
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.
Incidentally how should a link be made so that the CERN server multi
facility is used? Do i link to href="image." and it looks for
image.gif, image.jpeg etc? I didn't see anything in the CERN
documentation about this. Perhaps a short tutorial would be handy on
how to use multi?
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.
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.
-- Chris> The only way the client can optimize this is to avoid redundant > information - like having a long list of accept headers and then > '*/*'without quality factors.