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

• Mail folder: WWW Talk Jan 94-present
• Next message: mcclanah@dlgeo.cr.usgs.gov: "WYSIWYG HTML editor for the X Window System - comp.multimedia #13003"
• Previous message: bryan oakley: "<B> vs. <STRONG>, <I> vs. emphasis"
• In-reply-to: Ari Luotonen: "Re: CGI, semicolons, and so on..."

Message-id: <9401121556.AA18133@dxmint.cern.ch>
Date:         Wed, 12 Jan 94 10:51:27 EST
From: Rich Wiggins <WIGGINS@msu.edu>
Subject:      Re: CGI, semicolons, and so on...
To: Ari Luotonen <luotonen@ptsun00.cern.ch>, www-talk@www0.cern.ch
In-reply-to: Your message of Wed, 12 Jan 94 16:12:51 +0100
Content-Length: 1301

>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.
>
>CGI has NOTHING WHATSOEVER to do with how a server decides if
>a file is executable or not.
>
>One server writer could use x-bits to resolve executability.
>Another could use a fixed cgi-bin directory and a fixed prefix in
>URL pathname.  Another can have many of them, with generic mapping
>scheme.  Yet another can just list them in its config file.
>It's all up to server implementation.

This compartmentalization of protocol specs has its advantages,
but if you step back for a second, what you've just said is that
we're deliberately designing things so as to minimize portability
of HTTP/CGI/HTML works among servers.  Someone porting a corpus
that includes scripts is going to have to harvest all the
out-of-band signals and re-specify the information in the foreign
server's config files, exec bits, suffix, or whatever.

Yes, I realize we're not going to have portability of scripts
across platforms, but we seem to be explicitly defining away
compatibility across servers, even running on the same OS.

/Rich Wiggins, CWIS Coordinator, Michigan State U