[vox-tech] cgi-bin in user home dirs

[Jeff Newmiller]

On Mon, 10 Feb 2003, Jim Angstadt wrote:

> --- Tim Riley <timriley@timriley.net> wrote:
> > Jim Angstadt wrote:
> > > --- Tim Riley <timriley@timriley.net> wrote:
> > > > Jim Angstadt wrote:
> <snip>
> > >
> > > Thanks for the help.  I added both items to
> > > httpd.conf and then restarted httpd.  Then I
> > > keyed http://localhost/~ja/cgi-ja/test.cgi into
> > > the browser location bar and got a "Not Found"
> > > response.
> > >
> > 
> > This is expected. CGI scripts are not intended to
> > be called directly from the browser, instead they
> > are executed from the HTML post operation
> > located inside of a <FORM action="/cgi-ja/...">
> > tag.

This is a confusing set of questions and responses to me.  It seems like
you two may be using the same words to describe different things.

The only difference between the FORM invocation of a cgi script and
invocation by a link is that the user can enter information into the FORM
but has no direct input to the invocation of a script by a link.  If you
write a FORM GET cgi script (one that takes arguments as part of the URL),
you can invoke that script just fine with predetermined inputs using a
link. (It may not be common, but it is quite legal.) A FORM POST is not
something you can trigger with a link, though.

The term "called" here is the part I find confusing.  A cgi script
is "called" by the web server when the web server is configured to do so.  
We don't usually say a cgi script is "called" by a browser, though a
browser can request data from the web server... and that request may
prompt the web server to "call" the cgi script to get data to respond
with.  This may seem similar, but the term "call" is ordinarily used for
subroutines on one computer, or "remote procedure calls" that are
indistinguishable in the caller or callee from calls on one computer.  
The process of requesting data from a URL is not _usually_ referred to as
"calling", and may lead to confusion in general.

If you deliver a web page that contains a script of some sort (Javascript
being the most common), certain events such as pushing buttons or mousing
over areas may cause the web browser to "call" those scripts... which is
very different from requesting data from a web server and displaying a
whole new page.

Note that a cgi script need not respond with html... it may respond with
text, or with XML, or PDF... that is part of the flexibility this
request-response model offers.

> Thanks again for your help Tim.
> 
> Most of my local cgi scripts are called directly from
> an html link, not a form.  They have the html, css,
> and perl spread over several virtual pages.  So I was
> expecting that to be doable on a server.  (they are
> just fun scripts, not mandatory or business.)

To a certain extent, it will be.

> Also, it seems funny to have the test cgi script be
> callable (from a browser) from one location but not
> another.

CGI scripts run under the privileges of the user the web browser runs
under... or under configured privileges according to which cgi it is. In
either case, the entity triggering those cgi routines could be a malicious
user who finds security holes in your cgi and uses those to break in, or
retrieve data that could be of use in finding other weaknesses.  
Therefore, cgi scripts are often only stored in special directories that
the system administrator has access to, and that person will have to
accept responsibility for the coding quality of the cgis located there.

However, the system administrator, with appropriate configuration of the
web server, can grant you all the cgi access you desire in whatever
directory they want to.  That may not be a wise decision, but they _can_
do it.

In this case, I think the directory Tim suggested you put in the
configuration file didn't correspond with the directory you had specified
in your emails... (missing the "public_html" part), so your failure to get
that working may have been due to a typo.

> But, if that's a real limit, then I need to rethink my
> approach.  I had planned to get the scripts working on
> linux locally (they work on Window 98 and Apache,
> locally) and then move them to a friend's server. 

This is a perfectly workable plan, as long as you also plan to have your
friend go over them with you before installing them on a publically
accessible server, and you locate them in places compatible with the
layout your friend will require.

[...]

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------