gmane.network.gopher.general

[gopher] Robots.txt

Nick Matavka — 2012-05-23T20:17:59

Could I have the spec to, or perhaps somebody's explanation of, the
robots.txt file?  This will help me to explain it in my RFC.

[gopher] Minimalist Graphical Gopher Client

Damien Carol — 2012-05-23T15:54:34

Hello everybody !

I working on graphical gopher client.

(No java, it use C++ and QT.)

You can test it here : gopher://dams.zapto.org/1/gogoph-browser

To compile, install libraries for QT 4 and run :

$> qmake && make

THAT'S ALL !

Regards,

[gopher] caps.txt complete syntax

Nick Matavka — 2012-05-23T02:24:37

Doc (and other readers):

Would it be possible for you to please furnish the complete syntax of
capability files for Gopher?  This will make my job easier.

[gopher] Nmap 6 supports Gopher!

Kim Holviala — 2012-05-22T18:54:55

From the release notes at http://nmap.org/6/

"Nmap now supports the old-school Gopher protocol thanks to our handy gopher-ls NSE script. We even support Gopher over IPv6!"

I have absolutely no idea what that means... and I use Gopher and nmap almost daily.

(WTF is NSE?)


- Kim

[gopher] GOGOPH Server 2.4 release is out !

Damien Carol — 2012-05-22T15:06:55

 Hello gopherspace !

A new version for gopher server from GOGOPH project is out !

*What is GOGOPH Server ?*

GOGOPH Server is a gopher server (RFC 1436 compliant). The main goal is
simplicity.
The server display the content of the live folder to the world.

*Bundle ?*

This software is mainly a Java program. It use 1 configuration file.
All your need is archive file from HERE :
gopher://dams.zapto.org/1/gogoph-server

*Why choose this one ?*

Very small program.
Very small memory footprint. (files are loaded on-the-fly)
Design of gogoph server is KISS. Very simple to use. Only one program for
one configuration file (plain text) for one live folder..
Based on modern Java NIO framework, can manage > 1K connections in the same
time. You can't do that with inetd.
Effective asynchronous network framework with Netty (JBOSS open source
library).
NO external library or framework or whatever. Only need basic Java version.
(Works with open source implementations)
Can handle download of VERY big files ( > 100 Mo tested )
Can handle large number of files ( > 1K tested)
Use existing gophermap and/or gophertag files.

*New feature ?*

2.4
Compatible with Gopher+ clients (via special front-end Menu).

2.3
Use gophermap and gophertag files.

*Does it works with... ?*

Well Tested with :

  client

Lynx Browser

*ok*

client

UMN gopher client

*ok*

client

GOGOPH Browser

*ok*

proxy (HTTP)

Floodgap proxy

*ok*

proxy (HTTP)

Overbyte Firefox Plug-in

*ok*

*Can I change something ?*

YES, source code is very simple and accessible :
http://github.com/damiencarol/gogoph <https://github.com/damiencarol/gogoph>

*Can I say something ?*

YES, feedback are welcome:
* email at : damien.carol-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

Also whinning on "Gopher Project Discussion" <
gopher-project-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB< at >public.gmane.org> will do it.

[gopher] Line terminators in Gopher transactions

Nick Matavka — 2012-05-22T00:49:18

I understand that obsolete Mac OS sends CR as an EOL indicator, UNIX
sends LF, and Micro$haft Winblow$ sends CRLF.  How does all this get
fixed in Gopher?  What I mean is, how come a Windoze client, expecting
CRLF, is unburdened by a UNIX server sending it LF's only? Has Gopher
standardized on CR/LF/CRLF?  Is it the client's responsibility?  Is it
the server's responsibility?

[gopher] Mime under Nine

Denis Bernard — 2012-05-21T18:32:19

             Mimed File under Gopher Item Type 9

  Damien Carol made a proposal to use mimed file under the Item 0 to
carry all kind of binary files that could be base64 encoded; so, to be
assimilated to an ascii file. This proposal gave the possibility to
know which type of file is as reading the first blocks of that file
containing the label MIME. Furthermore, one could notice that using
"multipart", it is possible to know if that file is shortened or not
during the transmission according the boundary is displayed or not.
More, adding a checksum after this first part could verify the
integrity of the said file.

  Some persons said the item type "0" doesn't apply to this kind of
mimed file, even ascii encoded, due to the need to have a base64
decoder.

  From my side, I agree to the opinion that item type 0 must not be
used for mimed file.

  I saw, last days, many discussions about which item type to apply to
mimed file, PDF files, video files and so on. We all agree the fact
that item type is coded using only one ascii printable character. This
is the standard and we can't change it for instance. We could imagine
a renovation of the Gopher protocol where item type will be coded
using several ascii character. But, every year, it would be necessary
to write a new edition of the Gopher protocol!

  To day, there is much more types of text files or application files
than 20 years ago. Just considering the Unicode coded text files, you
have several flavors of UTF. For UTF-16, you have at the beginning of
the file a BOM (byte mark order) to tell if it is little-endian or
not.
So, many text files or application files hold a magic number at their
beginning. Just have a look at Wikipedia to have an idea of how many
magic numbers are in use to day:

http://en.wikipedia.org/wiki/Magic_number_%28programming%29

  An other indication of how many kinds of file are living to day is
the Iana page for mime media types at:

http://www.iana.org/assignments/media-types/index.html

  For people wishing a "p" Gopher item type standing for PDF files:
what about  presentation files (MS-PowerPoint), vCAL files, spread
sheet files, data base files or hundred flavors of text writer files?
There is so much file formats to day that applying a specific item
type is absolutely impossible with a unique printable ascii character!

  The idea of Damien of the client that reads the first blocks of an
unknown file is already an old implementation in the Unix world. The
Posix standard (now, SUSv4) provides the "file" command that make
several tests to find the type of a file, among of then by reading the
first blocks.
  On my Gentoo Linux, I have the package "sys-apps/file-5.09". Looking
at the source code, there is under the directory "Magdir", a huge list
of files giving magic numbers and their mime type. More interesting,
unlike the Posix version, it is possible to use the "--mime" option to
get the mime type!

  So, the idea of Damien to test the type of an unknown file is
possible for a client running under a Unix system. It could be done
via an external command or linking the program with "libmagic"
(#include <magic.h>). But, in practice, what happens?

  Supposing you get a menu Gopher having 10 unknowns files to test:
the client must connect again 10 times just to read the beginning of
that files. That seems heavy both for the client and the server. So,
is it hopeless? For me yes, assuming we consider only the primitive
Gopher protocol. Now, looking at the enhanced version of Gopher:
Gopher+ . There is an interesting gopher hole running both standards:

gopher://gopher.quux.org

 I suppose you have a Linux system and I suppose you have Netcat or a
Telnet client: run first this command in a console:

nc quux.org 70
or
telnet quux.org 70

then, press the "/" key and press "enter"

  You get the same menu than using the URL "gopher://quux.org/0/"
with any client.

  And now, again by "nc (or Telnet) quux.org 70", but:

press the "TAB" key, press the "$" key and press "enter"

  You get now a very different menu, because you are now using Gopher+
protocol:

(...)
+INFO: 0What's New      /whatsnew.txt   gopher.quux.org 70      +
+ADMIN:
 Admin: John Goerzen <jgoerzen< at >complete.org>
 Mod-Date: Tue Apr  2 21:16:57 2002 <20020402211657>
+VIEWS:
 text/plain: <1k>
(...)


  And what do you see there? A list of blocks with headers beginning
with “+” symbol, like INFO, ADMIN and VIEWS. The first one, “+INFO”,
provides the line of the gophermap that you know. The second one,
“+ADMIN”, provides several informations about name of administrator
and the date of last modification of the file. The third and last one,
“+VIEWS”, give the Mime type that we need to lunch the program
(external or internal) needed to process this file; and “<1k>” means
the approximate size of the file.

  So, the idea to introduce the Mime type in the Gopher protocol is
not recent! Please, read the Gopher+ description at:

gopher://gophernicus.org/0/doc/gopher/gopher+.txt

  If the idea of Damien of using a mimed file is not convenient from
client side, the idea of providing to the client the mime type needed
to apply the proper process for a given file is already described and
implemented to day: Gopher+ protocol! Implementation of Gopher+ in a
modern graphical client is up to you. There is no need to reinvent a
new Gopher protocol! 

  And what about my title "Mime under Nine"? My proposal is to
consider any file that do not clearly belong to "0","4","5","6","g"
and "I" item type to be under "9" item type.

[gopher] last call for OverbiteFF 3.0 beta comments

Cameron Kaiser — 2012-05-19T18:42:30

I want to get this into Mozilla's loving arms before Fx13 comes out because
there is a minor bug fix related to that version. Please report serious bugs
promptly. Assuming none, this will be uploaded to them probably next Friday.

gopher://gopher.floodgap.com/9/overbiteff.xpi

[gopher] Which itemtype for video (vote)?

Nick Matavka — 2012-05-19T16:18:36

Gentlemen and ladies:

It has come to my attention that the choice of item-type for video is
somewhat controversial.  The existing, but somewhat awkward, choice is
';' (semicolon), which is my own preference, but there are some who
have floated the idea of it being changed to 'v' (lowercase vee).  The
sole reason I prefer the semicolon is that it is the (unofficially)
established standard.  If the selector were changed, admins would have
to update their sites to accomplish the change, and some Gopher sites
are... shall we say... updated once in a bit over a millennium.
Furthermore, clients would have to be reprogrammed to accept the 'v'
selector as video.

Cordially,

Nick

vee: 0
semicolon: 1

[gopher] Soo sad today...

Damien Carol — 2012-05-19T09:15:53

my NAS is out...


4To fo data lost  :/

!!! NetGEAR ReadyNAS RND4000 !!!

[gopher] Gopher RFC propositions

Kim Holviala — 2012-05-17T18:36:27

printf("Hello, World!\n");

OK, so I've followed teh discussions about the proposed changes to the RFC. To be honest, I've not read of *any* change that would actually make sense. None of the changes proposed are backwards-compatible, and they really don't help the cause at all.

Say, the MIME thingy; yeah, let's decide that MIMEs are type M. Fine. What then? No client in teh whole universe supports such a filetype. And even if they did support it, why would I use it? I can serve out menus with type 1, text with type 0, html (which is stupid) with type h etc etc. There absolutely *no* need for sending out MIME, ever. Well... except for mailing list messages. But even then Jacob's neat mbox script works way better.

Anyway.

What I would like to see is (and I'm always right, so hear me out):

* what do about teh US-ASCII vs. Latin-1 vs. UTF-8 issue?
* are PDF's really type "p", or "d" - a definite list of filetypes
* should the server end the transmission with a dot or not?

And that's about it. Those are the *real* issues I've got (and since I'm always right, the world has) with the current RFC.

Other than those, I'd like to have an way for the client to advertise it's capabilities to the server. Currently, caps.txt handles the server->client capability exchange just fine, but the other way around is impossible. Thanks to the widespread usage of NAT server->client connection is impossible, so it has to be done some other way. I tried with extra headers, but they broke some of the servers still out there.

So, here's a proposition:

C:<opens up a TCP connection to victim.com, port 70>
C:caps.txt<TAB>Charset=UTF-8&ScreenWidth=120&UserAgent=Lynx&param1=value1
S:<sends out it's caps.txt>
S:<closes teh connection>
C:<opens up teh connection again>
C:<sends the real request>
S:<sends the reply to the real request>
S:<closes the connection>

Now, true, that will break some of the servers out there (yes, there are servers out there which cannot handle type 7 search queries). But it wouldn't really matter since they don't know about caps.txt anyway. And that way in one neat TCP session we'd get the client to advertise its properties to the server, and vice versa.

Second proposition:

Let's just forget that f*cking dot, mmkay? No dot, anywhere, ever. This doesn't break *any* of teh existing clients (yes, I've tried them all) and it won't break any of the servers either. On the positive side, we'd get rid of those text documents ending with a lone mistaken dot, and the whole confusion where no one really knows when to send the dot, or when the expect it.

As for the filetype problem, I've got a list in my sources. Not definitive, but pretty good. But I'm open for suggestions....

- Kim

[gopher] Support for MIME type

Damien Carol — 2012-05-17T11:07:39

Hello everybody !

I read the RFC of gopher 1.0 protocol and I can say that MIME is already
possible.

Read that :
1) MIME file is '0' type item
2) all clients are compatible they can get '0' type files

The file get is something like that :

*MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain

This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg=
--frontier--*


Clients can easily manage data because many lib exists to read MIME.

The only thing to do is to add feature to client that read the first line
of '0' type item.
If this line starts with "*MIME-Version:* " , then it's a mime encoded file
and client can offer to extract file or something else.

It's very very simple to manage mime type this way.

I will implements it in my client.

Give me few days to show you that possible and VERY simple to do without
redefine another RFC or break RFC 1436.

Regards,
ps: your opinions are welcome.

[gopher] ExitEnclave: revenge of Gor

Cameron Kaiser — 2012-05-17T00:47:40

https://trac.torproject.org/projects/tor/wiki/doc/ExitEnclave

Thinking about setting one up locally.

[gopher] Strange implementations of "Missing file"

Damien Carol — 2012-05-16T13:07:27

Hello everybody,

I'm facing a big pb with my search engine/crawler.

The crawler sends selectors that don't exists sometimes. (Updated / removed
/ don't exists / whatever)

I use to handle error like that :
1) parse response
2) Try to parse as Menu
3) If the first item of the menu is '3' error item type then ERROR

But this method don't works. Mainly because some servers reply very odd
responses

Some old servers sends that :

*BAD:*
==> 0Sorry, but the requested token could not be
found<TAB>Err<TAB>localhost<TAB>70
gopher://wss-ds.no-ip.info:70/0/robots.txt

==> 0'/robots.txt' does not exist<TAB><TAB>error.host<TAB>1
gopher://gdead.berkeley.edu:70/0/robots.txt
gopher://net.bio.net:70/0/robots.txt
gopher://newkraitch.cs.berkeley.edu:70/0/robots.txt
gopher://nemesis.cs.berkeley.edu:70/0/robots.txt
gopher://quix.us:70/0/robots.txt

=> <Empty String>
gopher://sdf.org:79/0/robots.txt

=> finger: /robots.txt: no such user
gopher://holviala.com:79/0/robots.txt


*GOOD:
gopher://gopher.r-36.net:70/0/robots.txt
gopher://jgw.mdns.org:70/0/robots.txt
gopher://grids.be:70/0/robots.txt
gopher://schot.a-eskwadraat.nl:70/0/robots.txt
gopher://www.quux.org:70/0/robots.txt
gopher://dams.zapto.org:70/0/robots.txt
gopher://go.nickshanks.com:70/0/robots.txt*


It's very strange. I can understand the "Empty String" could be an easy
implementation. But others servers sends Menu with 0 items as info...

Does it old implementations ?

[gopher] Found treasur

Damien Carol — 2012-05-15T17:57:56

Hello !

My crawler found a treasur.

Yeeehaaar !

=> gopher://gopher.viste-family.net/1/NES/

[gopher] Need advice

Damien Carol — 2012-05-15T09:32:04

I'm working on Gopher Client and I have a pb.

My client works with URL.

But for type item 7, I don't know how to manage them.

Basically what my client do :

URL =  gopher://example.com/7/search?foo%20bar      =>     request to [
example.com] port [70] wtih selector [/search<TAB>foo bar]

BUT there are many gopher sites that use '?' in there selectors :/   what a
crap !

Another detail, in RFC 4266 specify that '?' character is reserved for ASK
Gopher+ feature.

What's your opinion gopherspace ?
Regards,

[gopher] Finally: Chrome extensions have real sockets

Cameron Kaiser — 2012-05-14T19:30:52

It's only in Canary. But finally we can ditch the proxy kludge and
Overbite Chrome can be a real gopher client just like OverbiteFF.

http://blog.alexmaccaw.com/chrome-tcp-udp

[gopher] Capability files are dangerous

Denis Bernard — 2012-05-14T08:48:48

Capability files are dangerous!

  Overbite Project provides a module for the Internet browser FireFox
to ease Gopher netsurfing. This project is going to promote a
capability file (caps.txt) to be installed inside a Gopher server.
This practice is dangerous for users of the Gopher space and the
administrators of Gopher servers.

  Up to day, any Gopher client was able to deal with any Gopher server
(more or less). The spirit of Gopher is to keep it as simple as
possible and, mainly, for retrieving files anonymously. Up to day, it
was impossible, for an administrator of a Gopher server, to know which
flavor of a Gopher client was browsing its site. The only information
available was from the IP address. Now, with a capability file like
“caps.txt”, there is a fingerprint. Without to be paranoiac, everybody
heard of web sites serving contents (or refusing to serve!) according
the software or the system that the client have. That will happen for
the Gopher space too!

  A capability file creates an indirect kind of permanent connexion by
a kind of proxy. That is the opposite practice of the gopher space
until to day. We have seen, by the past, how much loss of privacy and
security did cookies in the World Wide Web. Does it must be the same
for the Gopher space?

  Worse, this will encourage the propagation of scripting languages
that aims to bring more intelligence to the browser or more
intelligence to the server. We already know, as seen in the Web world,
what this perversion produced: chaos.

  To day, there is only one modern browser available for Gopher
netsurfing and only one capability file. Next month, you will have
an enthusiast developer branding a new Gopher browser... and a new
flavor of capability file. Next year, you will have 10 brand new
Gopher servers... and 10 flavors of capability files.

  Without to be paranoiac, everybody heard of malicious scripts
infecting Web browsers or malicious code making Web servers slaves.
Everybody heard of government in some countries that take care of the 
mental health of their citizens. Forging an inoffensive Web client, a
government can check the illness of a particular Gopher user.

  That is, in short, for clients. Now, for you administrator:

  A capability file offers interesting informations about the Gopher
server software version that you run and its hardware. Knowing the
version of the capability file, the version of the software of the
server, it is easy to deduce how much the administrator is lazy or
incompetent.

  You can find, in a capability file, private informations provided
by its unadvised administrator like the geographical position of its
server. So, if somebody claims that you are serving a file under a
copyright that you don't hold, knowing the city where the server runs,
he can easily find the door of the competent justice court. If you do
not provide that kind of information, jurists will have to ask to the
Internet provider who are you according your IP address (supposing
your domain name is kept in anonymity). It takes time and they need to
have strong motivation to do that.

  Providing a precise resource at a root Gopher server, like a well
known capability file, makes this server vulnerable to a massive
attack. Until to day, if a Gopher server is flooded by requests, it
just have either to display a root menu file (gophermap) or an error
message. The other resources can stand on other severs: thanks to
Gopher protocol to be a distributed system! If you provide a
capability file, your server must have to reply the full content of
this additional file requested. You can tell me that is the the same
with a resource that doesn't exist: server replies with a short
message of one line. But, for a capability file, the reply is much
more long than an error message. And do not forget that: next year,
you will have to play with 10 flavors of capability files!

  You are advised, now. Have fun!

[gopher] OverbiteFF 3.0 beta

Cameron Kaiser — 2012-05-12T03:27:08

OverbiteFF 3.0! Now with caps!

This needs testing, so this is a beta with debugging on. Locales are
incomplete.

Caps support right now allows you to navigate "up" paths. Eventually it
will be expanded. Because threading extensions is a bit tricky in Firefox,
the caps is fetched when an "up" is requested and then cached. If it turns
out there is no caps, then the root is fetched as a bailout. Caching is
for the life of the browser instance, since this is simpler, but if you
visit pseudo-URL gopher:/// it will be cleared out.

There is machinery already to display a formatted caps display, but that's
all it supports right now. But this is now the first "major" client to
support caps and Overbite Android will be next once the kinks are worked
out of OverbiteFF.

The code is based mostly on the Public Proxy.

Firefox 3.6+ required (current SeaMonkey also okay). Fx10+ or TenFourFox
recommended. This is a beta only.

gopher://gopher.floodgap.com/9/overbiteff.xpi

[gopher] Overbite Chrome WFM

Cameron Kaiser — 2012-05-11T21:51:29

I just tried Overbite Chrome on Chrome 18 on my Mac mini, and it works fine
with gopher:// URLs in the omnibox. So you must have a different search URL.
Please send me what search URL you get when you type in a gopher:// URL so
I can compare it.

[gopher] New gopher proposal

Christoph Lohmann — 2012-05-11T14:23:34

Greetings,

in  accordance  to the discussion on this list about some maybe flaws of
gopher I wrote down a simple proposal on how to do gopher but  including
the modern ideas.

http://sprunge.us/DMSE

The whole proposal does break backwards compatibility and I don’t expect
it to be adopted, because one intention of this  mailinglists’s  efforts
is   to  preserve the old gopherspace and its history. Maybe it is worth
to do another gopherspace?


Sincerely,

Christoph Lohmann


_______________________________________________
Gopher-Project mailing list
Gopher-Project< at >lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project