Re: [gopher] Gophernicus Server 0.5 released
Dne 06.04.2010 (tor) ob 08:58 +0300 je Kim Holviala zapisal(a):
> 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.
Ah, that explains it all ...
>
> > 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++/
I taught it would be possible to implement some of the features, not all
of them. I see now they are tightly connected to each other, its almost
impossible to implement just virtual hosts for example ...
Thanks for the explanation. I guess I'll have to wait for the final
implementation of your server and the specification :-) But I will start
experimenting at least with some of your ideas before that.
Matjaz
_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/gopher-project
Reply to: