Mailing List Archive

On Wed, 15 Mar 1995, Robert S. Thau wrote:
> So, if we go with the content-arb stuff, the DirectoryIndex patch
> would potentially wind up being a bit redundant. I guess I should ask
> --- do we actually want the content negotiation? I've included again
> the reference info on what my current code does below.

Just to talk off anyone's ear who hasn't heard me go off about this yet -
yes, we need this badly, especially now that some browsers are doing HTML
3.0 things like tables (wink wink nudge nudge) and people are screaming
because their (NCSA, WN, etc) servers won't let them do the right thing.

And I'm presuming Rob has helped convince Lou that adding the one line of
code needed for content-negotiation to the core of netscape would be a
good thing. Here's even a patch:

fprintf(out, "Accept: text/html; level=3\r\n");

Replace "out" as needed, of course. Hope this helps :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/

From: Nicolas Pioch <pioch@grasp.insa-lyon.fr>
Date: Wed, 15 Mar 1995 18:17:22 +0100 (MET)

One advantage of CERN/WN?/NCSA servers are that you have the source. If you
don't like something, modify it! At the end of this message is the patch for
NCSA httpd1.3 (it should also works for httpd1.3R) to support:

[1] user defined DirectoryIndex (use same authorization check as AddType)
[2] multiple DirectoryIndex

NB, the next spin of my content-arb code will have a similar effect
--- MultiViews will be active on directory indexes, if selected for
the directory, meaning that a "DirectoryIndex index" would allow the
server to arbitrate between index.html and index.html3 as it would for
any other retrieval, and even to invoke index.cgi if that's what
happens to be lying around.

So, if we go with the content-arb stuff, the DirectoryIndex patch
would potentially wind up being a bit redundant. I guess I should ask
--- do we actually want the content negotiation? I've included again
the reference info on what my current code does below.

FWIW, this code is due for at least one respin, which will involve:

*) getting Content-encodings to work
*) doing something with level= parameters, so arbitration between
"text/html" and "text/html; level=3" works
*) getting MultiViews and DirectoryIndex to interact properly
(it's pretty clearly a bug that they don't)

After that, IMHO, it will be at least alpha-ready.

I also plan, over the weekend, to do make a separate patch which does
*something* about includes in html3, but it may just be adding another
magic type --- fixing this really right, with type attributes, is
doable in terms of my own coding effort, but involves enough changes
to http_mime.c to potentially pose a problem for integration.

rst






HERE'S THE DOCS:

This code adds two new features to httpd: special treatment for the
pseudo-mime-type application/x-type-map, and the MultiViews
per-directory Option (which can be set in srm.conf, or in .htaccess
files, as usual). These features are alternate user interfaces to
what amounts to the same piece of code (in the file http_mime_db.c)
which implements (uh, ...most of) the optional content negotiation
portion of the HTTP protocol.

Each of these features allows one of several files to satisfy a
request, based on what the client says it's willing to accept; the
differences are in the way the files are identified:

*) A type map names the files explicitly
*) In a MultiViews directory, the server does an implicit glob
and chooses from among the results

TYPE MAPS:

A type map is a document which is typed by the server (using its
normal suffix-based mechanisms) as application/x-type-map. The syntax
of these files is simple:

filename: mime/type; parm parm parm
filename: mime/type; parm parm parm

so, for instance, you can have

foo.gif: image/gif; q = 0.6
foo.jpeg: image/jpeg; q = 1.0
foo.xbm: image/x-xbitmap; q = 0.00001

The 'q', for 'quality' parameter, specifies preferences among these
images if the client doesn't much care --- in this case, the jpeg is
somewhat preferred to the gif, and the xbm is only shipped if the
client won't take *anything* else.

Note that the files references *must* be in the same directory as the
map file, for security reasons (we wouldn't want someone coming in
through an ftp server to be able to fake up a map file listing
/etc/passwd, and have the server respect it). You get a Server Error
message if they aren't. (Also, if HTML or HTMLish files in other
directories were retrieved through this mechanism, relative links in
those files would be broken, barring proper <BASE> tags or the use of
a server redirect).

Note also that to use this, you've got to have an AddType someplace
which defines a file suffix as application/x-type-map; the easiest
thing may be to stick a

AddType application/x-type-map map

in srm.conf.

MULTIVIEWS:

This is a per-directory option, meaning it can be set with an Options
directive within a <Directory> section in access.conf, or (if
AllowOverride is properly set) in .htaccess files. Note that Options
All does not set MultiViews; you have to ask for it by name. (This is
a one-line change to httpd.h).

The effect of MultiViews is as follows: if the server receives a
request for /some/dir/foo, /some/dir has MultiViews enabled, and
/some/dir/foo does *not* exist, then the server reads the directory
looking for files named foo.*, and effectively fakes up a type map
which names all those files, assigning them the same MIME types it
would have if the client had asked for one of them by name. It then
chooses the best match to the client's accept: headers, and forwards
them along.

If one of the files found by the globbing is a CGI script, it's not
obvious what should happen. My code gives that case gets special
treatment --- if the request was a POST, or a GET with QUERY_ARGS or
PATH_INFO, the script is given an extremely high quality rating, and
generally invoked; otherwise it is given an extremely low quality
rating, which generally causes one of the other views (if any) to be
retrieved. This is the only jiggering of quality ratings done by the
MultiViews code; aside from that, all Qualities in the synthesized
type maps are 1.0.

Note that this machinery only comes into play if the file which the
user attempted to retrieve does *not* exist by that name; if it does,
it is simply retrieved as usual. (So, someone who actually asks for
'foo.jpeg', as opposed to 'foo', never gets foo.gif).