On 09/06/07, Rob Burns <[EMAIL PROTECTED]> 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev