Re: CGI, semicolons, and so on...

• Mail folder: WWW Talk Jan 94-present
• Next message: Bert Bos: "Re: PATHs in HTML"
• Previous message: =?iso-8859-1?Q?Bj=F8rn_Remseth?= : "Re: PATHs in HTML"
• Maybe in reply to: Tony Sanders: "Re: CGI, semicolons, and so on... "

Message-id: <199401121831.MAA07495@austin.BSDI.COM>
To: www-talk@www0.cern.ch
Subject: Re: CGI, semicolons, and so on... 
In-Reply-To: Ari Luotonen's message of Wed, 12 Jan 1994 16:12:51 +0100.
Organization: Berkeley Software Design, Inc.
Date: Wed, 12 Jan 1994 12:31:37 -0600
From: Tony Sanders <sanders@BSDI.COM>
Content-Length: 1939

Ari Luotonen writes:
> Mark A. Krause wrote:
...
> > What if I want to run a server on a DOS PC or a Macintosh?  I think it is
> > important to make sure that GCI is not OS specific.  The continued growth
> > of the Web is going to depend upon how easy it is to get new servers up
> > and running.  Not everyone is going to have access to a UNIX system for
> > this.
>
> There is constant confusion about what the CGI specifies.  Let's
> make it clear:
> 
> 	CGI specifies the interface between HTTP server and
> 	a script: the command line args, environment variables,
> 	standard input and standard output.
Just to be clear, the CGI *is* OS specific because it requires things like
command line arguments, environment variables, and stdin/stdout.  I don't
think you can define an interface at this level without being somewhat
OS specific.

> CGI has NOTHING WHATSOEVER to do with how a server decides if
> a file is executable or not.

You are correct that CGI *does not* specify how to determine if a file is
executable but let me clarify that CGI does (potentially) impact the URL.
If scripts are to be portable then the URLs themselves must be portable.
That means that CGI must also define how the server decodes the URL (to
some extent anyway).

Let's consider all the known schemes for determining "scriptability":
	;
	cgi-bin
	.cgi (or other magic extension)
	xbit
	config file
The portability constraint requires that any scheme adopted must work on
all servers.  So, if a scheme requires special processing by the server
(like ";" might, depending on how it's used) then it must be covered by
the CGI spec.  e.g., http://server/foo;/arg1/arg2 is probably ok but
http://server/foo;arg1/arg2 is not.

There isn't anything wrong with adding special decoding in the server for
some format (e.g., forms), but it will require coverage in the CGI spec
and all CGI servers must support it (or else it's not really useful).

--sanders