CGI in Mac Classic (8.6)

[Alain Farmer]

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