CGI in Mac Classic (8.6)

[Pierre Sahores]

Alain Farmer a écrit :
> 
> Hello Robert and y'all,
> 
> > Alain, you may want to provide a few more details
> > of your setup as the above is somewhat confusing.
> 
> Server-side = MacPPC running WebStar. HyperCard-based
> CGI program with the script at the bottom of this
> post.
> 
> Problem = When the HTTP request comes from a web
> browser (Netscape 4.7.2 in this case), then the CGI
> does exactly what it's supposed to. But, OTOH, when
> the request comes a MetaCard 2.4 stack. e.g. by using
> MC's built-in syntax for doing this (get url myURL),
> is does NOT work at all. When the request comes a
> MetaCard 2.5 stack, again using the same native MC
> syntax (get url myURL), then it works once. Subsequent
> requests from the MC 2.5 client result in this error
> msg "Error previous request not completed" and
> eventually followed up by this msg: "socket timeout
> 132.208.44.158:8016925". The IP in this last error-msg
> is my server's IP (the one hosting my HC-based CGI).
> 
> > Where are the sockets coming in from?
> > Not on the server I think.
> 
> According to the error-msg it is the *server*.
> 
> > As I understand, your CGI talks to a web server
> > program (are you using MacHTTP or sth else?)...
> 
> WebStar (which in turn uses MacHTTP, I believe).
> 
> > using AppleEvents.
> 
> That is how the CGI protocol is implemented in Mac OS
> Classic. It's AppleEvents or nothing in this case.
> 
> > The web server talks to a client using HTTP
> > protocol. If the client uses an MC stack instead
> > of a normal web browser, it still has to talk HTTP
> > to the server.
> 
> I totally agree with you, and this is indeed the case.
> 
> > So if there is a problem, it would seem to have
> > nothing to do with your CGI per se but with the
> > client stack.
> 
> At first blush, it does indeed seem to be a problem
> with the CLIENT. The web-browser client handles it
> perfectly, but the MC clients don't. Hence the easy
> conclusion that it is the client who is a fault. But
> what about the 2nd error-message that points the
> finger at my SERVER? What if the server's CGI is not
> providing *all* the required HTTP-headers that are
> needed by the MC-2.5-client? Web browsers, you see,
> are rather tolerant when it comes to HTTP headers. Not
> long ago, and for several years, all of my CGI
> programs did NOT provide ANY HTTP-headers at all..
> none.. nada .. and yet it worked liked a charm. It
> still does work without any HTTP headers at all when
> the client is a commonly-used web-browser.
> 
> > Or are you trying having the client stack bypass
> > the server and talk directly to CGI? If so, your
> > CGI must act as a server not as a CGI then.
> 
> No. Not at this stage of the game. But I will be soon,
> when I complete my first MetaCard-based BLOG client,
> e.g. direct communication to server-side programs via
> XML-RPC. Btw "RPC" stands for "Remote Procedure Call".
> 
> > Robert
> 
> Thanks for trying, Robert, but I'm afraid my problem
> remains un-solved. Below are my client-side and
> server-side components needing to be debugged :
> 
> ========= Server-side CGI =========
> 
> on appleEvent class,event,sender
>   if class is "WWW*" and event is "sdoc" then
>     put the short date into content
>     put the number of chars of content into cLength
>     get minHeadersHTTP(cLength) & content
>     reply it
>   else
>     pass appleEvent
>   end if
> end appleEvent
> 
> function minHeadersHTTP contentLength
>   put the numToChar of 13 & the numToChar of 10 into
> crlf
>   put "HTTP/1.0 200 OK" & crlf into headers
>   put "Server: MC/2.3 ID/ACGI" & crlf after headers
>   put "MIME-Version: 1.0" & crlf after headers
>   put "Content-type: text/html" & crlf after headers
>   put "Content-Length:" && contentLength & crlf & crlf
> after headers
>   return headers
> end minHeadersHTTP
> 
> ========= Client-side MC stack =========
> 
> Download it (608 bytes) :
> 
> http://ufp.uqam.ca/MC/clientStack.sit
> 
> __________________________________


Hello Alain,

Your problem as to do with the use of the first one of the two below :

> set httpheaders to "Content-type: application/x-www-form-urlencoded" & return
> post retour to url (fld "csrecents" of cd 2 of stack "ccitalis")

You must test and test again to find how the mc httpheaders command need
to be set. The above code works under linux but must probably be tunned
to work under MacOS 8 + WebSTAR.

Be carefull, too, about the urlencode/urldecode commands on both the
client and server side. As an example, they need to be set differently
on the linux and the macosx client-side front-ends, even if the
server-side is always the same (linux, in my case).

After getting the right tunning, your code will become 100% sure and
secure. MC is not in fault.

Hope this helps :-)

Bests, Pierre