Re: accept extension
Wed, 28 Jun 1995 11:48:30 +0100 (BST)

Message-Id: <>
Subject: Re: accept extension
To: (Brian Behlendorf)
Date: Wed, 28 Jun 1995 11:48:30 +0100 (BST)
In-Reply-To: <> from "Brian Behlendorf" at Jun 27, 95 11:34:25 am

Brian Behlendorf wrote:
> On Tue, 27 Jun 1995 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


> 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

Stewart Brodie
Dept. Electronics & Computer Science, Southampton University, UK.   <-- running on my Risc PC