Re: [gopher] Gophernicus Server 0.5 released
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
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: