> Chris Lilley wrote:
>> But at the moment (re the other current thread about the online
>> newspaper) if a client asks for newspaper.html 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.
Agreed. I hoped that was obvious. I deliberately picked an example of
an undesirable (and curently topical) conversion which, currently, the
clients seem to be saying they would accept.
> 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.
I was arguing for putting information into the link that aided this
process, so the client could give it better information to perform this
content type negotiation than simply all possible things the client
could ever accept; such as, what it might like for the current request.
For example, a link could be tagged as belonging to a class of
documents that are text searchable. So the client might send an Accept
of text/html, text/plain, application/x-pdf and anything else that the
users' mailcap indicates that has contiguous searchable text strings in
it. image/gif, for example, would not fall into that category, neither
would, say, application/postscript.
> That's the point.
Sure
> Are you saying the spec should prohibit this?
No. I am saying that the process should be made easier so it actually
gets used. In particular, I would like, for example, HTML 3 browsers to
be able to say they can accept html 3. I would like to reduce the risk
of clearly undesirable conversions such as the example I gave.
-- Chris