That's the major stumbling block, I agree. I was merely suggesting a
method for incorporating the clients wishes in the HTTP protocol.
Maybe one could construct simple scripts for determining such information
and have a mapping in the server's configuration between the types and
the 'file information' scripts.
>
> Also, Accept: doesn't have any way to express the statement "send me a
> PNG of the *lowest* bitdepth you have, please" - we'll need that unless
> we can assume that a given "level" of a document also implies
> compatibility with earlier levels.
You would need to fix this by specifying different q factors for different
bit depths eg.
Accept: image/png; q=0.8; colordepth=1
Accept: image/png; q=0.7; colordepth=8
Accept: image/png; q=0.6; colordepth=24
etc.
>
> In general, though, I think this kind of fine-tune negotiation should
> occur as *close* to the client as possible - so that if three people
> behind the Hensa proxy cache want different bitdepths of the same image,
> hensa can download the canonical version of the image and downconvert
> accordingly if it wants, rather than store three different versions.
This would mean building in the graphics conversion software to the proxy
server. I do not know what the proxy stores, but I presume it needs to
remember most (all?) of the headers which the real machine sent. What if
the server wishes to send different images depending on the available
bitdepth?
-- Stewart Brodie Dept. Electronics & Computer Science, Southampton University, UK. http://louis.ecs.soton.ac.uk/~snb94r/ http://delenn.ecs.soton.ac.uk/ <-- running on my Risc PC