Date: Thu, 24 Oct 1996 09:23:00 +0100 (BST)
From: Paul Sutton <paul@ukweb.com>
To: new-httpd@hyperreal.com
Subject: Re: custom variations with ErrorDocument
In-Reply-To: <199610231859.TAA09415>
Message-ID: <Pine.LNX.3.92.961024091225.9756A-100000@star.ukweb.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Wed, 23 Oct 1996, Rob Hartill wrote:
> I was looking at the dull output one gets if an appropriate variant
> can't be found to serve the request..

>      index.html.en type text/html language en
>      index.html.de type text/html language de
>      index.html.fr type text/html language fr

> Not very pretty, and not in keeping with customised ErrorDocument pages
> elswhere on folks sites.

I would like to see a (optional) third argument to AddType, AddLanguage,
etc so that you could do

  AddLanguage en en "English"
  AddType text/html html "HTML document"

so the variant list could like much nicer:

  HTML document in English
  Plain text document in German and French

(or whatever). Only problem is that these directives are handled by
mod_mime, so aren't accessible to mod_negotiation....

> So how do we pass the above information to a custom script ?
>
> Here's a 1 line patch that sets an ENV var to hold the information.

> REDIRECT_HTTP_VARIANTS = index.html.en (;text/html;en), index.html.de (;text/html;de), index.html.fr (;text/html;fr)

> .. a ", " separated list of relative URLs followed
> by (description;type;language)

Yes, I like this idea. But I wonder if the format used shouldn't be the
variant-list format from the Holtman draft for transparent content
negotiation. This is already created (if using tcn), and could easily be
created in all cases. The format, btw, would look like this:

  { "index.html.en" 1.0 {type text/html} {language en}}
  { "index.html.de" 1.0 {type text/html} {language de}}

etc. Note that additional {...} sections could also appear, such as
{charset ...} and {description } and (in the future) {features ...} (the
latter will give browser-specific features, such as screen size, media,
whether it can support tables, java, etc). I think this format would be
more extensible, since the CGI can just ignore any attributes it does not
understand.

Paul
--
Paul Sutton, Technical Director, UK Web --- http://www.ukweb.com/~paul/
Apache Week: Latest news on Apache server... http://www.apacheweek.com/