Complete.Org: Mailing Lists: Archives: gopher: March 2004:
[gopher] "groxies"
Home

[gopher] "groxies"

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: gopher@xxxxxxxxxxxx
Subject: [gopher] "groxies"
From: Cameron Kaiser <spectre@xxxxxxxxxxxx>
Date: Sun, 14 Mar 2004 20:50:34 -0800 (PST)
Reply-to: gopher@xxxxxxxxxxxx

Due to some research on a project I'm working on (sssh! all will be revealed
very soon), I'm looking at methods of proxying Gopher through today's
firewalls. Myself, I use SOCKS on my own internal firewall (I get arguably
higher throughput than NAT with it), but I like the simplicity of HTTP
proxies and how very little work has to be done for the client.

The scheme I'm proposing for a "groxy" is simple. Instead of

request\r\n

a groxy accepts

host\tport\trequest\r\n

and does The Right Thing with it. This won't break Gopher+, either, because
the idea scales right along:

host\tport\g+request\t+\r\n

Even if a data flag and block follow, you should be able to see it won't
interfere with that either.

Any concerns over an implementation like this for a prototypical "groxy"?

One other idea I had was allowing gopher to tunnel through HTTP as a method
of getting around ignorant site administrators that block port 70. A HTTP
groxy could accept GET requests to it in the same form an HTTP *P*roxy would,
but would execute a gopher request on the other side and return the document
with the right MIME type or application/gopher-menu as appropriate.

Comments?


-- 
---------------------------------- personal: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Floodgap Systems Ltd * So. Calif., USA * ckaiser@xxxxxxxxxxxx
-- People who buy computers from TV commercials *deserve* PCs. ----------------


[Prev in Thread] Current Thread [Next in Thread]