[gopher] Gophernicus Server 0.5 released

Kim Holviala kim at holviala.com
Tue Apr 6 05:58:10 UTC 2010


On 5.4.2010 23:05, Matjaž Mešnjak wrote:

> These are interesting features. But how do I (a client) know I am
> talking to a gopher++ server?

You don't. A gopher0 server won't get mad at gopher++ headers so the 
client can send them anyway. And a gopher++ server doesn't get any 
headers from gopher0 client and will just give the client a response 
based on defaults. Perfect backwards and forwards compatibility. If both 
client and the server talk gopher++ then they get additional features, 
but neither party can assume those.

Yes, it would be nice for a gopher++ client to know about the server and 
vice versa, but then we're back in the HTML/HTTP lala-land where it 
"works best with Nutscrape/1.0".... I really don't want anyone coding a 
gopher++ only client, or gopher++ only server. By expecting the 
unexpected it all works much better.

> Another thing .. About virtual hosts support. Now that is even more
> interesting. Currently you implement it like this:
>
> 1Display string<tab>selector string;virtual.host<tab>host<tab>port

That's just the fallback if nothing else worked. Usually the virtual 
hosting works without any special selectors.

> When I add support for virtual hosts in my client, I would like it to
> work automatically - I want the client to automatically select
> appropriate selector and follow it, instead of asking the user to select
> the correct selector.

The above ;vhost trick was mostly for unmodified gopher0 clients asking 
for the root selector - if you're modifying the client you're better off 
doing it the proper gopher++ way using request headers (sorry about the 
lack of offical documentation):

C: <opens the connection>
S: <accepts the connection>
C: selector<TAB>[query]<TAB>GOPHER/++<CRLF>
C: Filetype: 1<CRLF>
C: Host: domain.com[:port]<CRLF>
C: Charset: UTF-8<CRLF>
C: Columns: 80<CRLF>
C: User-Agent: Nutscrape/1.0 (MS-DOS 6.22 NecV20)<CRLF>
C: <CRLF>
S: <Sends the document>
S: <closes the connection>

The Filetype parameter specifies the type the client expects to get in 
return, Host is the host the client thinks it's connecting to, Charset 
is one of US-ASCII/ISO-8859-1/UTF-8 and the client chooses one that 
suits it the best, Columns specifies the width of client screen and 
User-Agent is just an informational header for the server. Originally I 
also specified the Referer header but I'm not sure if that's a good 
thing - Gophernicus Server does parse that header but my gopher++ 
patches to Mosaic won't send it.

 > For that to be possible the selector string should
> be less ambiguous - e.g. instead of:
> selector string;virtual.host
>
> something like:
> selector string;vhost=virtual.host

That was just a fallback, it was not supposed to be a carrier for extra 
parameters. The headers described above are the primary request 
parameter carrier.

> Also, file names containing ";" are valid in *nix and windows and that
> could be misinterpreted as a virtual host by a client, that would try to
> do it automatically.

There aren't too many chars that aren't valid in *nix filenames, and 
those usually mess up the URL. I chose semicolon because you'd have to 
be crazy to use it on a filesystem...

> BTW, this "redirecting to virtual host" should only be applied when the
> client wants a root directory of virtual host, otherwise the selector
> string already contains virtual host part ... or am I wrong?

You're close, but not quite... If we forget the gopher++ headers 
described above (as Host: already specifies the virtual host) it works 
like this: if there's a ;vhost in the selector, the server uses that 
vhost. If there isn't, the server guesses the vhost the client wanted... 
Sounds a bit strange but it works really well - the only problem is the 
root selector which is why we're using the ;vhost trick with it.

Try it out - all of the code is out there. And if you don't want to 
install your own server just test with gopher://holviala.com and 
gopher://gophernicus.org which are just to vhosts running on top of the 
same ip address.

gopher://gophernicus.org/1/software/gophernicus/server/
gopher://gophernicus.org/1/software/patches/gopher++/


- Kim






More information about the Gopher-Project mailing list