> From: Andu <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 23 Nov 1999 20:11:19 -0500
> To: [EMAIL PROTECTED]
> Subject: Re: More questions about mchttpd server
>
>
>>
>> Isn't that just how WEBSTART ET AL DO IT. The information must be coming
>> from the browser into the server socket, no? If so, then mchttpd does not
>> have to use applevents surely?
>
> On the mac cgis usually work this way: the sever gets the request and forms
> data from the client and all it does is to pass it as appleEvents to an
> application to process it and send the result back to the server which in
> turn sends it to the client. In this scenario the server is an intermediary
> between the client and the application which processes the forms data.
> Mchttpd has or will have the unique advantage of processing the forms data
> itself eliminating the need for cgis. This is also valid for the other
> platforms.
>
>
>
>
> Regards, Andu
>
>
Thanks, I think that's what I figured. I was wandering how to keep the
"compatibility" with ".mt", perl and other cgi's (not really apple events).
The question is more, how do I program a CGI which can easily be ported to
Perl, or ".mt" scripts? As these ways of implementing CGI's rely heavily on
the "Environmental variables" defined I think by the server??? then it makes
sense to implement them by scripting stuff like:
put the legnth of putStuffComingfromStdin into $CONTENT_LEGNTH
> From: Andu <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 23 Nov 1999 19:55:13 -0500
> To: [EMAIL PROTECTED]
> Subject: Re: More questions about mchttpd server
>
>> Does this go for things like REQUEST_METHOD, or QUERY_STRING, or
>> HTTP_USER_AGENT, which would seem to only make sense when set by the server?
>>
> These are not exactly environment variables.
>
> Regards, Andu
>
OK, how do they differ? My perl book calls them environmental variables. Can
I access and set them with "get $REQUEST_METHOD"? Would it be better to use
globals? If mchttpd sets them, does that make them accessible to a perl or
other program?
> From: Scott Raney <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 23 Nov 1999 14:44:14 -0700 (MST)
> To: [EMAIL PROTECTED]
> Subject: Re: More questions about mchttpd server
>
> On Tue, 23 Nov 1999, David Bovill wrote:
>
>>> But you can also set them yourself (for example for a CGI) by just
>>> putting the value into variables named $whatever prior to starting up
>>> the CGI process. Note that this doesn't apply to MacOS which has no
>>> concept of environment variables (CGI on the Mac is done with
>>> AppleEvents instead).
>>
>> Isn't that just how WEBSTART ET AL DO IT. The information must be coming
>> from the browser into the server socket, no?
>
> Right, that's how it gets to the HTTP server.
>
>> If so, then mchttpd does not have to use applevents surely?
>
> I guess it depends on what you're trying to do. If you're trying to
> explain how CGI programs typically work on the various platforms,
> understanding stdio and environment variables (for Windows and UNIX)
> and AppleEvents (for Mac) is important. I had the impression that
> that's what your goal was.
A transparent, easy to program cross-platform server, which would act as an
easy entry to learning and implementing a dynamic web site - would be a kind
of mission statement. It would seem to make sense to implement environmental
variables as it would seem that most CGI's need them (even if they are
implemented as Andu has sugested), and doing it this way would:
1) facilitate eventual porting to other cgi environments (ie if your
aim was rapid prototyping), and
2) teach cgi principles (if your aim is eventually to learn perl etc).
>
> If all you want to do is add custom handlers to mchttpd, the problem
> is a lot simpler. Andu has come up with an idea where you can just
> add a script to the message path with "start using" or "insert script"
> and mchttpd can just call that handler if you get or post to a URL
> that doesn't have an extension in its name. This will be a lot faster
> and more efficient than the way CGI is done on the other platforms,
> and immensely easier to debug. It's just not compatible with the way
> it's done with other HTTP servers (though it is similar to the way
> it's done on most Java-based servers).
> Regards,
> Scott
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
>
I like this idea. The problem I am having with it at the moment is that
according to a recent post adding a new cgi will only be possible in the
full development environment. If I am right this is because setting the
script length to greater than 10 lines will not be possible in the starter
kit. The only solution is to "do" 1 line at a time, or limit cgi's to 10
lines!
