Re: custom authentication functions

> Again, that would depend on how CGIs are implemented. I can easily
> imagine a server implementing Tcl CGIs as simply sourcing and then
> invoking the code in an interpreter, for example.

Ouch. Sounds hazardous to the health of your server. I've had one
server author tell me that he didn't do something ala NSAPI for that
very reason. There are safe solutions along the line of sourcing the
Tcl file - and they're all proprietary.

> I think as the web gets more commercial, the proper payment headers would
> become more important. I think the real problem is that the standards for
> the new and exciting things are falling far behind what people want to
> do, forcing them to use CGI to implement stuff that the server could be
> doing itself if it were standardized.

This is pretty much a generic problem on the net. That's why you get
proprietary solutions to invoking customer-provided code, proprietary
extensions to HTML, etc. I certainly don't plan on implementing SET in
CGI; I'll use the servers proprietary interface.

> > This sounds like a typical ISP to me :-).
> Typical ISPs don't let their users install CGI.

I hope that's "typical shrinking ISPs". The ones I deal with all let
their users install CGI - at least the users who pay for virtual

> I think it would be better to simply say that the presense of
> VARIABLE_FILENAME in the environment indicates that the variable is being
> passed in that file.

Yeah - I like that one. The advantage that this kind of solution has
is that it can all be hidden inside the CGI module for your favorite
language, the module has a chance of being portable, and isn't hard to

> Or perhaps that *all* variables are being passed in
> the file whose name is in FILENAME.
> Ick ick.

I think ick is right for this one.


Received on Saturday, 30 March 1996 02:11:46 UTC