- From: <S.N.Brodie@ecs.soton.ac.uk>
- Date: Wed, 28 Jun 1995 11:48:30 +0100 (BST)
- To: brian@organic.com (Brian Behlendorf)
- Cc: www-html@www10.w3.org
Brian Behlendorf wrote: > > On Tue, 27 Jun 1995 www-html-request@www10.w3.org wrote: > > How about extending the Accept header to pass this information. > ... > > Accept: image/png; q=0.8; colordepth=8, image/png; q=0.7 > > > > which would be interpreted as: "if you have an 8 bit colour PNG, send it; > > otherwise send me any PNG you have". > > So by what mechanism should the server determine arbitrary, > non-meta-informational attributes of the files it has available to serve, > without have to code up a lot of content-type-specific smarts into the server > itself? I.e., if a request on the file similar to the unix command "file" > returned a attribute/value pair listing, then maybe that would work, but > that's not something every content-type has natively. 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
Received on Wednesday, 28 June 1995 06:48:25 UTC