[cs631apue] Question about CGI

[Jan Schaumann]

ccui1 <ccui1 at stevens.edu> wrote:

> We run the server like ./sws -c ./usr/cgi_bin ./usr/htdocs
> (1) Assume we both have ./usr/cgi_bin/foo and ./usr/htdocs/cgi_bin/foo
> These are two different files with the same name.
> One is under cgi_root, the other is under server root.
>
> Now a quest like GET /cgi_bin/foo come to the server.
> How can we handle this request? We process it as a cgi request or a  
> normal request?

The "-c" flag specified that content found by the name "./usr/cgi_bin"
under the document root would be served as a CGI.  That is, if a request
comes for:

GET /usr/cgi_bin/foo HTTP/1.0

...then you would serve it as a CGI.

A request for

GET /cgi_bin/foo HTTP/1.0

would be served as a regular file, since "/cgi_bin/" is not the same as
"/usr/cgi_bin".

> If we run the server like ./sws -c ./usr/cgi/test ./usr/htdocs
>
> Now the cgi root is ./usr/cgi/test.
>
> What kind of request is regarded as a CGI request?

GET /usr/cgi/test/foo HTTP/1.0

would be treated as a CGI.

> Do we need to force that a request staring with a /cgi_bin/ is a CGI  
> request?

No.  Only requests starting with the string given to the '-c' flag
relative to the document root are treated as CGIs.

Now we _could_ also stipulate that *if* the '-c' flag specifies a
directory outside of the document root, then any request for
"/cgi-bin/foo" would be translated to that path.

If you choose to implement this, then that's fine, too.

> If the cgi root is ./usr/cgi/test/
> The request is GET /cgi_bin/dir/subdir/file HTTP/1.0.
> We finally regard the request as ./usr/cgi/test/dir/subdir/file.

No, that is not what the manual page says.

> If this is the case, what if there are the same path and files under  
> both CGI root and the server root. Which one will be used?

A request matching a CGI path will take precedence.

> (2)Will the -l and -d options override each other?
> If both of these two flags are given, which one will effect the server?

The two are independent.  "-d" enables logging of all system events to
stdout.  That is, wherever you've used syslog(3) to log events
previously, you now log those messages to stdout.  This does not
constitute request logging, which is what '-l' enables.

The reason for this is that the debugging mode is supposed to be useful:
you want to see debugging information while running the server in the
foreground, but you do not need to see all requests being logged (on a
normal web server, that would be hundreds per second) -- those should go
to a file and are logged without syslog(3).

-Jan