Message-ID: <20040315061346.99985.qmail@web60205.mail.yahoo.com>
Date: Sun, 14 Mar 2004 22:13:46 -0800 (PST)
From: "William G. Davis" <william_gordon_davis@yahoo.com>
Subject: [gopher] Re: "groxies"
To: gopher@complete.org
In-Reply-To: <200403150450.UAA13420@floodgap.com>
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
Hi Cameron.

I like the concept very much. My only concern is over
how you'd be able write a server that could act as
both a "groxy" and as a normal content server at the
same time on the same port. The protocol already has a
variable number of tab delimited fields in the request
line as it is, and choosing which ones to accept and
which ones to ignore can be difficult (e.g., is that
second field the search string or Gopher+ field?).

Why not put the added information on a line by itself,
then put the actual request on the lines after it? For
example:

groxy-host\tportCRLF
slector\t+CRLF

Or maybe—if you wanted to make things even easier to
parse—prefix the hostname/port combo with some special
character:

#groxy-host\tportCRLF
selector\t+CRLF

--- Cameron Kaiser <spectre@floodgap.com> wrote:
> 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. ----------------
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com