[webkit-dev] Accept- & Content-Resolution headers proposal

[Windy Road]

On 09/06/07, Rob Burns <robburns1 at mac.com> wrote:
> That is great (though ironic) to hear that this feature's been there
> all along (at least in the spec and in the server). I wonder if you
> (Nicholas) could write up or point to some instructions on
> configuring that in Apache (ideally the exact lines to add to the
> config filie).  This would help implementors and just help raise
> awareness for server admins (as the word spreads).

I've had a quick look at the Apache docs and I was able to create a
very quick demo using Apaches type-maps by uncommenting the line:

AddHandler type-map .var

in the httpd.conf

I then created a file called image.var as follows:

URI: image

URI: image-1200x1000.jpg
Content-type: image/jpeg; qs=0.9

URI: image-600x500.jpg
Content-type: image/jpeg; qs=0.5

URI: image-300x250.jpg
Content-type: image/jpeg; qs=0.25

URI: image-150x125.jpg
Content-type: image/jpeg; qs=0.1

Testing this in Firefox (sorry I don't have my iBook handy at the
moment) results in Apache selecting the content with the highest qs.

However, from what I can see, Apache does not support the "feature
negotiation" portion of the RFC, so there is no way to specify in the
type-map anything other than:

URI:
    uri of the file containing the variant (of the given media type,
encoded with the given content encoding). These are interpreted as
URLs relative to the map file; they must be on the same server (!),
and they must refer to files to which the client would be granted
access if they were to be requested directly.
Content-Type:
    media type --- charset, level and "qs" parameters may be given.
These are often referred to as MIME types; typical media types are
image/gif, text/plain, or text/html; level=3.
Content-Language:
    The languages of the variant, specified as an Internet standard
language tag from RFC 1766 (e.g., en for English, kr for Korean,
etc.).
Content-Encoding:
    If the file is compressed, or otherwise encoded, rather than
containing the actual raw data, this says how that was done. Apache
only recognizes encodings that are defined by an AddEncoding
directive. This normally includes the encodings x-compress for
compress'd files, and x-gzip for gzip'd files. The x- prefix is
ignored for encoding comparisons.
Content-Length:
    The size of the file. Specifying content lengths in the type-map
allows the server to compare file sizes without checking the actual
files.
Description:
    A human-readable textual description of the variant. If Apache
cannot find any appropriate variant to return, it will return an error
response which lists all available variants instead. Such a variant
list will include the human-readable variant descriptions.

And currently, only the following dimensions of negotiation are supported:

Media Type  	Browser indicates preferences with the Accept header
field. Each item can have an associated quality factor. Variant
description can also have a quality factor (the "qs" parameter).
Language 	Browser indicates preferences with the Accept-Language
header field. Each item can have a quality factor. Variants can be
associated with none, one or more than one language.
Encoding 	Browser indicates preference with the Accept-Encoding header
field. Each item can have a quality factor.
Charset 	Browser indicates preference with the Accept-Charset header
field. Each item can have a quality factor. Variants can indicate a
charset as a parameter of the media type.

So it looks like even if support for this is added to webkit, we will
still need to wait for it to be implemented in Apache or another
browser before we can test it.

Has anyone else found anything that suggests otherwise?

Cheers,

-- 
Tom Howard
http://windyroad.org