[gopher] gopher++ (gopher1) protocol

[Mateusz Viste]

On Monday 11 January 2010 10:22 (CET), Kim Holviala wrote:
> So yes, a gopher++ client sends an empty CRLF when it's done with the 
> headers. A gopher++ server is required to read the gopher0 selector and 
> wait for some predefined time for the extra headers (0.01 seconds?) and 
> if the extra headers don't come it's expected to handle the request as 
> gopher0.

That's not a way to go.
What if the TCP packet containing your second line got lost? The TCP
retransmission mechanism won't resend it in those 0.01 second.
As I wrote before, there *must* be some kind of a flag in the very first
line of the Gopher request, which would indicate to the server wheter it
has to wait for other lines to come or not.

> I thought about that but couldn't figure out a clean way to do it. Maybe 
> the client could request a special selector (say, "server-status") which 
> would then contain machine-readable information about the server. Even 
> gopher0 servers could then provide server-status just by serving out a 
> static text file.

What about a CAPABILITIES selector? That's already used in NNTP and POP3,
and probably in some other protocols...

> If the server cannot transcode the resource then the resource is sent as 
> is.

That's not what you wrote before: "the server MUST send its reply using
the format the client requested.".

Anyway, the whole transcoding idea seems odd to me. The client already
know what to expect, as that's specified in the gopher URL by the gopher
type... Plus, you're limiting the protocol to some specific file format,
which is plainly wrong.

About the "Accept-Charset" header: It seems useless to me... The server
won't be able to transcode a given 8bit charset into another one, as
that's simply impossible. Why not simply stating, that any Gopher++
document *has* to be provided in UTF-8?

Best regards,
Mateusz Viste