Re: [gopher] Gophernicus Server 0.4 released (renamed from kgopherd)
Kim Holviala <
kim@...>
2010-03-29 15:26:29 GMT
On 2010-03-29 15:50, Cameron Kaiser wrote:
>> I also wanted virtual hosting which is pretty much impossible without
>> any changes to the protocol. Or so I though... with enough creative
>> hacking that was _also_ solved fairly reliably. So yes, I have support
>> for virtual hosting with plain gopher0 - compatible with all clients.
>
> Interesting. It seems like it saves state about what it last served, or
> some such?
See /server-status, that lists all the sessions it's tracking.
> I'm trying to figure out the rules it's using (though I suppose
> I could just go look at the source :-D ).
The source is VERY well commented mostly because it's the only way I'll
be able to grok it - my memories last for about 15 minutes and then I'm
mostly blank.
Anyway, here are the rules in order, and the last one wins (that is,
we'll go through the whole list):
* $HOSTNAME
* -h option
* previous hostname from the session data
* whichever vhost has the file pointed by selector (using stat())
* the hostname after the semicolon in the selector
That's pretty much it, from memory. It's been more than 15 minutes since
I looked at the code so I might be completely wrong....
(Continue reading)
. First of all, kgopherd is now known as Gophernicus Server. Yes, I plan to do a client too once I'm done with the server... After a long hiatus I finally got back to coding and finished some of the things I set out to do with my gopher server. Since you all seemed *cough cough* a bit cautious about my gopher++ additions I decided to do as much as I could without any changes to the protocol. Turns out most of the thigs i wanted to accomplish were doable with a little hacking and cheating.... My first problem with the protocol was that the server didn't know the filetype what the client was requesting. That's pretty much solved without any changes to the protocol. Related to that was the problem where the client had no idea what kind of data the server was sending - that's also pretty much solved as the server now sends back whatever the client expects. The next problem I had was with charsets. That's solved, kind of, but not properly yet. Bascially I scrapped iconv() and made my own charset conversion function which is input autoconfiguring and can output US-ASCII/Latin-1 and UTF-8. The current version only outputs US-ASCII which is compatible with all clients - problem solved but it could be better (how does the server know when to output UTF-8?). I also wanted virtual hosting which is pretty much impossible without any changes to the protocol. Or so I though... with enough creative hacking that was _also_ solved fairly reliably. So yes, I have support
RSS Feed