httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (David Robinson)
Subject Re: indexing suggestion
Date Sun, 16 Apr 1995 16:48:00 GMT
Rst wrote:
>  From: (David Robinson)
>   >I'd like to see Apache act on the MIME type mapping for .idx
>   >instead of having "/cgi-bin/idx/" prefixes to URLs.
>   So how about a mime type for running a CGI script. .e.g.
>   AddType application/x-script-parsed .idx /cgi-bin/idx
>   The specified script would be called with the document URL as PATH_INFO,
>   and the document file as PATH_INFO_TRANSLATED.

>I *really* like this idea... here are a few possible improvements.
>Instead of overloading PATH_INFO, give the script the document URL as
>DOCUMENT_URI, as is currently done for server-side includes.  This is
>a bit more consistent with the includes functionality, and it also
>lets the script get at the real PATH_INFO, if any was supplied.

Yes, probably better, although DOCUMENT_URI isn't part of the CGI spec.
Currently you can only have PATH_INFO for server-side includes or CGI scripts.
(See below.)

>Also, instead of having a three-argument AddType directive, it might
>be better to have a separate AddHandler directive --- this would allow
>users to easily declare handlers for a MIME type with multiple
>suffixes, or for their DefaultType, without having to repeat the name
>of the handler several times, e.g.
>   AddHandler text/plain /cgi-bin/format_setext_stuff

I think this would be amazingly useful. For example, the patchlog database
runs each patch file through an html converter for sending to the user.
So you read a patch with a URL like
Currently, this could be slightly better if the id was passed in the path
info as http://host/dir/bugread.cgi/00001

Whereas with your suggestion, I would be able to present the bug files as
and httpd would automatically run the cgi script to format the file.

That way, the index produced by http://host/dir/bugs/ would have links which
would return the formatted documents, rather than the plain files. 

Re PATH_INFO; if /dir/file.ext is a regular (unix) file, then accessing
/dir/file.ext/path_info will fail. Should this still apply if file.ext
is subject to a CGI handler? If the use of handlers is as 'output filters',
then httpd should probably reject such a request. However, I imagine there
might be cases where the files don't represent objects to be filtered, so
extra PATH_INFO might be useful. 

And how about using this mechanism for content-type based translation?
Suppose the request specifies acceptance of image/gif files, but not
image/jpeg, and a jpeg version does not exist. Then we might have
AddTranslator image/jpeg image/gif /cgi-bin/jpeg2gif
Obviously, this could be done with an AddHandler CGI script which
checked the Accept headers.

>Finally, substitute directory indexing routines could be declared as
>handlers for an appropriately chosen MIME type, say
>   AddHandler application/x-unix-directory /cgi-bin/read-4dos-indexes

How would this interact with the multiple DirectoryIndex config?


View raw message