|>>1 is solved best through use of MIME multipart type. The browser does
|>>a request and gets back the complete object as a single document,
|>>inline images and all. This is currently being added to the library
|>>but slowly :-(
|>
|>I'd not agree with this; the client, not the server, knows what the
|>client wants. It's also very hard to make this backward-compatible,
|>since most existing clients can't handle multipart messages (can't
|>even hand them off to an external viewer.)
No the server knows as well because the client sends an accept field.
Of course if the client sends Accept: */* with no quality field and does
not know what to do with it then the system will break.
I had an idea to deal with this, ammending the content type so that
a */* match without quality field defaulted to q=0.01 and have a cutoff
for sending multipart if the q factor was not > 0.1
We can call it the M-Kludge.
(because its needed for MIME - what did you think it stood for?)
-- Phillip M. Hallam-BakerNot Speaking for anyone else.