Re: More CGI Comments

• Mail folder: WWW Talk Jan 94-present
• Next message: Kevin 'Kev' Hughes: "Re: minimal HTML"
• Previous message: rhb@hotsand.att.com: "Passing info between pages"
• Maybe in reply to: Robert S. Thau: "More CGI Comments"
• Reply: Robert S. Thau: "More CGI Comments"
• Reply: Rob McCool: "Re: More CGI Comments"

From: rhb@hotsand.att.com
Date: Sun, 9 Jan 94 20:04:00 EST
Original-From: hotsand!rhb (Rich Brandwein)
Message-id: <9401100104.AA07753@hotsand.dacsand>
To: www-talk@library.ucsf.edu
Subject: Re: More CGI Comments
Content-Length: 3372

>    All my scripts have a #! notation at the top.  I would think looking
>    for any files of this type would indicate scripts (though this may
>    be unmanageable/inefficient).
> 
> Good idea.  There are two complications.  First off, to make this work
> properly, you need to check for the binary executable magic numbers, in
> addition to '#!', so the server can run C programs as 'scripts'.  (Such
> programs exist --- imagemap, for one).
> 
> The other, more serious, complication is that if some binary data file
> happens to begin with a magic number, the server would refuse to serve it
> up (instead trying, and failing, to run it).  If I'm not mistaken, most
> common binary data formats (Sun .au, AIFF, JPEG (JFIF), MPEG, tar,
> compressed data...) define their own series of magic numbers which are
> unlikely to conflict, but relying on this would be dicey.

This in fact points up the need to have a "smart" server.  It is important
that the server be able to identify the files it's serving not just by their
suffix (i.e., in the mime type file) but via any available attribute
(such as magic numbers).  The information that's available differs
among platforms and application (server) needs.  I'm in agreement that
we need a flexible method that allows the server to use it's "smarts"
and the users' needs (e.g., the scripts I am interested in providing
are all perl and tcl, so the #! would work for my application...).

> However, I could live with any of these alternatives.  What would be nice
> at this point would be to develop a consensus around one of them, and get
> it into the servers, so that users could actually have the capability
> (where, of course, the server administrator feels it proper to grant it).

Based on some limited discussion here, I propose the following: 

Add to the srm.conf file:
***************************

# UserExec: Whether local user executables is activated
# 

UserExec True
***************************

Add a .srm_conf file in the users public_html directory
(or whatever it's set to in the server's srm.conf file)
***************************

# ScriptAlias: This controls which directories contain server scripts.
# Format: ScriptAlias fakename realname

ScriptAlias /cgi-bin /home/rhb/myscripts


#and possibly a line that includes info on how I identify 
#my executable files

ExecAlias magic, suffix=exe
***************************

Now a more general question that turns the previous question inside
out.  The original concern was in adding executables to directories
that were not indicated as having executables.  Well it seems that
I can certainly have "regular" (non script) html files in executable
directories.  What do I gain from having a directory "not executable"?
Why aren't all directories cgi-bin directories?  I can restrict
GET in the directories in which I really have scripts if I'm concerned
about reading scripts...

One point brought to my attention is that all directories are already
"executable" in the NCSA server environment via the <inc var> directive
(i.e., this takes care of my original problem of getting to the
user variable in authentication), but it doesn't take care of things
like forms.

Rich

> 
> rst

By the way - I'm continuing to receive all kinds of spurious messages
from the listserv server (e.g., the error messages for unknown users
are returned to me...).