From: Cameron Kaiser <spectre@floodgap.com>
Message-Id: <200403150450.UAA13420@floodgap.com>
Subject: [gopher] "groxies"
To: gopher@complete.org
Date: Sun, 14 Mar 2004 20:50:34 -0800 (PST)
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org
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@floodgap.com
-- People who buy computers from TV commercials *deserve* PCs. ----------------