From: Cameron Kaiser <spectre@floodgap.com>
Message-Id: <200403151645.IAA17822@floodgap.com>
Subject: [gopher] Re: "groxies"
In-Reply-To: <20040315061346.99985.qmail@web60205.mail.yahoo.com> from
 "William G. Davis" at "Mar 14, 4 10:13:46 pm"
To: gopher@complete.org
Date: Mon, 15 Mar 2004 08:45:07 -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

> 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

This would work fine for Gopher+ servers, but non-Gopher+ servers would
probably see the groxy-host\tport portion as a request (Bucktooth, for
example, would definitely get confused).

I wasn't intending to have a dual-headed server like you suggest in any
case (although the idea is quite attractive), so if there's no other way
other than to make a groxy "just a groxy," this is not a showstopper.

However, the more I think about the other idea of tunneling gopher over HTTP,
the more I like it. It would be easy to add it to an existing proxy like
Squid, too. A simple "stupid" groxy would be simplest to implement, though.

-- 
---------------------------------- personal: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Floodgap Systems Ltd * So. Calif., USA * ckaiser@floodgap.com
-- What the large print giveth, the small print taketh away. ------------------