About CGI and custom protocol

[me]

Hi,

I'm in development of a CGI (in C) which can be used already through a
browser to perform the tasks it was developed for.

Now, I'm trying to do a terminal-based program I can use to connect to
such CGI, and perform certain administration duties without the need
for a browser.

So my program sends a regular HTTP (POST) request to the CGI that
grants me access as admin same as it would if through a browser. From
then onwards, I'd like to be able to keep the communication pipe
somehow open, and let both comunicate with each other with a clever
and binary protocol, instead of HTTP.

I think it's because of the CGI spec itself, that apache (which is the
one I'm using for testing) won't allow bi-directional comunications to
happen on a cgi other than on a per-request basis (other servers might
behave the same), such that I can use a single request to switch to my
own protocol and send/receive several commands and their answers in a
row.

I can confirm so far that reading stdin from my cgi (after the content-
data has been read) results in void, no matter how much data I send to
it from my terminal-based program aftwerwards, so can only send from
the CGI, and never receive beyond that point.

Because regular web hostings services won't allow outgoing connections
at all, I might need to be able to reuse web-server's file
descriptors', or else, get stuck with HTTP, which I'd like to avoid
where possible.

Some of them won't allow forking CGI's either, and even if they would,
I'd have yet to solve how to inherit file descriptors without breaking
the already established connection.

Amazingly, I've found something called `websockets', which is another
"standard" from the "clever" guys at W3 allowing full-duplex
comunications to take place as I'm trying to, thing that could have
been solved by just introducing some mechanism to allow stdin to be
passed to the underlying script, but well, if they'd even know how to
develop a proper protocol, HTTP wouldn't be text-based, and HTML
wouldn't be another bolated crap causing relevant pollution to the
atmosphere due to unnecesary bandwidth and electrical-power waste at
both ends.

So, has anybody done something similar before and/or can give me some
things?

Thanks,

[Randal L. Schwartz]

>>>>> "me" == me <ecost...@gmail.com> writes:

me> Now, I'm trying to do a terminal-based program I can use to connect to
me> such CGI, and perform certain administration duties without the need
me> for a browser.

At this point, you're off track. So much wrong. Please rethink this.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

[Ivan Shmakov]

>>>>> me <ecost...@gmail.com> writes:

[Cross-posting to news:comp.infosystems.www.misc, just for the
case.]

> I'm in development of a CGI (in C) which can be used already through
> a browser to perform the tasks it was developed for.

> Now, I'm trying to do a terminal-based program I can use to connect
> to such CGI, and perform certain administration duties without the
> need for a browser.

I'd like to note that there /are/ browsers that are
terminal-based (such as Lynx.) Also, HTTP servers could be
queried using tools such as GNU Wget, or libraries, such as the
Net::HTTP Perl module.

> So my program sends a regular HTTP (POST) request to the CGI that
> grants me access as admin same as it would if through a browser.
> From then onwards, I'd like to be able to keep the communication pipe
> somehow open, and let both comunicate with each other with a clever
> and binary protocol, instead of HTTP.

Such a task seemingly demands the CONNECT HTTP method, not POST.

[...]

> Because regular web hostings services won't allow outgoing
> connections at all, I might need to be able to reuse web-server's
> file descriptors', or else, get stuck with HTTP, which I'd like to
> avoid where possible.

Such outgoing connections are also incompatible with HTTP
proxies and NAT's, which both are quite widespread these days.
I don't think popular hosting services will allow for CONNECT,
either. (That being said, VDS'es are quite cheap these days,
and will likely allow for any TCP- or UDP-based protocol.)

[...]

> Amazingly, I've found something called `websockets', which is another
> "standard" from the "clever" guys at W3 allowing full-duplex
> comunications to take place as I'm trying to, thing that could have
> been solved by just introducing some mechanism to allow stdin to be
> passed to the underlying script, but well, if they'd even know how to
> develop a proper protocol, HTTP wouldn't be text-based, and HTML
> wouldn't be another bolated crap causing relevant pollution to the
> atmosphere due to unnecesary bandwidth and electrical-power waste at
> both ends.

I don't quite understand this part. How on Earth W3C, formed in
October 1994, may be held responsible for HTTP, which is in use
since 1990 (as per RFC 1945)?

Also to note is that HTTP was (IIRC) designed after SMTP, which
dates back to 1981. But then, even FTP (1971) is ASCII-based,
thus adding yet another decade to the whole concept.

[...]

--
FSF associate member #7257 http://sf-day.org/