Re: accept extension

S.N.Brodie@ecs.soton.ac.uk
Wed, 28 Jun 1995 11:48:30 +0100 (BST)


From: S.N.Brodie@ecs.soton.ac.uk
Message-Id: <29799.9506281048@strachey.ecs.soton.ac.uk>
Subject: Re: accept extension
To: brian@organic.com (Brian Behlendorf)
Date: Wed, 28 Jun 1995 11:48:30 +0100 (BST)
Cc: www-html@www10.w3.org
In-Reply-To: <Pine.3.89.9506271147.i10466-0100000@eat.organic.com> from "Brian Behlendorf" at Jun 27, 95 11:34:25 am

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