[Webkit-unassigned] [Bug 10359] Change WebKit website to use Apache MultiViews for content negotiation

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=10359


opendarwin.org at bdash.net.nz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |opendarwin.org at bdash.net.nz
            Summary|fixes for website           |Change WebKit website to use
                   |                            |Apache MultiViews for
                   |                            |content negotiation




------- Comment #6 from opendarwin.org at bdash.net.nz  2006-08-14 00:41 PDT -------
(In reply to comment #4)
> Darin:
> It allows for easy changing of the file type used to generate resources. For
> example at the moment the site is serving flat HTML files with a .html name
> extension. If at a later date we should wish to change them to PHP files, it
> would require changing all the links from .html to .php. We may then decide
> that was a bad idea and have to change them all back again. By just leaving off
> the extension, we afford ourselves much more freedom to change/add/remove the
> implementation details for any individual resource.

While this is nice in theory, it's troublesome to deal with correctly under
Apache 1.3.  Apache 1.3 uses a fake MIME type of application/x-httpd-php on
.php files to pass them off to mod_php.  Unless the client specifies that it
will handle application/x-httpd-php in the "Accept" request header (either
explicitly, or via */*) they will see the wonderful "406 Not Acceptable" page. 
When I last looked, Googlebot only included text/html in the "Accept" header of
its requests.

> It also allows apache to serve multiple files for a single resource, depending
> on what the user has requested. e.g.
> User sends GET /resource   Accept-Language: fr, en;q=0.5
> Apache serves /resource.fr.html
> User reads page in preferred language
> -or, say-
> User sends GET /resource   Accept: image/gif, image/jpeg, image/png
> Apache has three variants available, gif at 200KB, png at 150KB and bmp at 180KB; since
> the browser cannot understand bmp, it discards that from being selected, then
> checks quality values. pngs have been configured at q=1.0, and gifs at 0.5,
> final values are png = 150KB/1.0 = 150,000; gif = 200KB/0.5 = 300,000. Then it
> serves the one with the lowest score (i.e. highest quality to file size ratio),
> so /resource.png
> 
> Apache can only do content negotiation if you leave off the file extensions.

This is only partially true.  Apache can only do content negotiation based on
MIME type if the request URL omits the file extension, but it can do
language-based negotiation even when the request URL includes the extension.

> It's the most powerful and under-used feature of apache IMHO. I will repost
> with a changelog (didn't realise there was a need for one for the website).
> 
> Dave: could you give a reason as to why you prefer the filenames to be left as
> they are? I would strongly disagree with doing that, for the reasons explained
> to darin above.

While using content negotation to provide a multi-lingual website or more
diverse range of file formats is a nice idea, they are completely lacking in
practicality.  We have no non-English content for the website nor anyone to
create and maintain it, and the addition of extra graphical assets in other
formats would increase the ongoing effort required for maintenance while
providing almost no extra value.  Nice in theory, not very useful in practice.

Personally I would rather see '.html'-less URLs, but that is mainly based on
aesthetics.  Some form of technical justification can be found in the W3Cs
"Common HTTP Implementation Problems" (http://www.w3.org/TR/chips/),
specifically guideline three.  The benefits are mainly theoretical, and the
various problems with Apache makes dealing with these issues in the correct
manner sufficiently painful that few websites bother to do it.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.