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 __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard