[gopher] Re: ASK blocks in practice

[David Allen <s2mdalle@xxxxxxxxxxxxx>]

On Tue, Jan 30, 2001 at 07:30:25PM +0100, Stefan Rieken wrote:
> 
> OK, so you want a better ASK, _without_ having to change client
> software?

Yup.

> You do realize you're asking for a real hattrick, do you? :-)

Damn.

> But having worked all day debugging my own ancient and buggy CGI script,
> I'm in to some REALLY ugly hacks right now, so here goes! ;-)
> 
> (rhetoric) What are the current client's capabilities?
> * After selecting anything, be it a normal file, an index file, or an
>   ASK file, the client expects back a directory listing or a file of any
>   data type

I don't think this is correct.  The only way that the client can know
what type the data coming back is by looking at the selector of the
thing that has the ASK block attached to it.  I just tried a trial by
creating a perl script which just printed a bunch of protocol
information to STDOUT, something along these lines:

#!/usr/bin/perl
print "0Something\t0/Something\tgopher.mothra.dyndns.org\t70\r\n";
print ".\r\n";

and the client dutifully displays this as text, not a directory.  I
tried this on the UMN gopher client.  (Using the UMN server).  It does
this because the locator that's sending back this data isn't flagged
as a directory, since you can hardly dynamically execute a directory.
:) I can't find anything in the spec that says that the client should
try to "guess" what kind of data is coming back. What seems to be
needed is something along the lines of HTTP, where you have the first
line being text/html, etc. 

> The problem lies in the fact that the ASK part of the protocol is so
> over-simplified that the client and server can only handle a predefiend
> amount of predefined variables.

Yep.  And there isn't even any type of input type=hidden hack, where
you could do something like encode what kind of data is coming in the
first field where the user couldn't change it.

> At this point, it is important to note that the Gopher and Gopher+
> protocols do provide a wealthy set of extension possibilities. It should
> really also be considered to just introduce a new datatype, a new file
> attribute, or extra data after the extra "\t" or after the "\r\n". While
> these solutions would require server AND client to be adapted in order
> to recognize this new extension, this _is_ a very clean way of dealing
> with this problem, the cleanest way around. You should really consider
> using these capabilities.

After the "\r\n"?  How would that then be distinguisable from data
belonging on the next line?

One of the reasons that I'm skitting about extending things like this
is that people can't even seem to agree on gopher+ all of the time,
and I can understand why, since it does seem contradictory in places.
At any rate, something that's going to extend the way gopher actually
works, (which would definately be in a totally backward-compatible
fashion) needs to not be a one-man show.

> The /only/ capability a client has to ask the user for a variety of
> data, is the current ASK implementation. So we _have_ to use it as our
> basis. On top of that, the client should be able to send the server
> *more information* about the data it sends in return to an ASK block, or
> about the data it needs to ask in the first place. To give this extra
> data in a compatible way, I see no other way then to hide it in the
> selector string.

Yep, I've considered this, something along the lines of:
1/Some/selector?var1=value1&var2=value2&var3=value3

But this then jumps into the tarpit of encoding of various characters,
particularly tabs, and disallowing & and ? in the name of legitimate
selectors.  Unless encoded.

> Let's illustrate what we have with an example. This example script first
> asks you for your username and password, and if that is OK it will let
> you see other data (don't care what). If the password is not OK, it will
> tell you so, give you the opportunity to try again, or to register.
> Let's see how this will work:

I follow your example up to...

> * The script examines the values and does whatever it has to do with
>   them. If the username and password are not correct, it may decide to
>   spit out a directory listing similar to this one:
> 
>     iBad username or password\thost.org\t\t1
>     1Try again\thost.org\tpath/to/script?username&password\t70\t?
>     1Or make a new
>     account\thost.org\tpath/to/script?newname&newpassword&retypepw\t70\t?
> 
>     [please ignore any protocol mistakes I made, this is tongue-in-cheek
>     stuff]

This is a problem.  See above with the question of whether or not a
script can legitimately output directories.

> Summary
> =======
> The above example shows a way (a "method and apparatus" -- let's get one
> of them fancy software patent for this rubbish! ;-) for a Gopher+ server
> to enable the client to pass a variable amount of named variables to a
> server-side script without requiring any extra intelligence on the
> client side. It is an ugly hack by nature, but it might be useful. If it
> turns out to be so, work still needs to be done on defining the exact
> syntaxis of the query, and on the protocol for the dialog between the
> server and the script.

I think it would be useful.  The question in my mind is whether or not
the effort is the same or exceeds simply extending gopher.  And is
extending gopher really even an option?  Sure it's fun to have your
own private hacked server, but it does no good it 90% of the planet is
using LameClient version 3.0 which can't talk to your extensions.

> This method vaguely resembles the GET method in HTTP, where data is sent
> as part of the selector. In more complex cases, this method leads to
> very ugly URLs. The POST method hides the data from the user.

See, if you're going to add GET, then why not add POST?  And if you're
going to do that, why not do it in a clean way by extending rather
than hacking in the above fashion?  But then again, if we're going to
implement GET and POST, then how long before somebody asks for
cookies?  Do we want to reimplement HTTP in gopher?  :)  (I.e. is
there a limit past which it isn't really appropriate to extend gopher,
because you're playing in HTTP's sandbox, and why reinvent the wheel?)

> It might be considered to also provide a POST-like solution for sending
> our [meta]data which new clients would recognize, while older clients
> would handle the GET-like method, similar to the way Gopher clients may
> ignore Gopher+ extentions. I haven't had time to give that a thought,
> and as I have to go away now, it'd be for another occasion.

Well, the way ASK data is passed to programs right now is really like
POST since it's all coming in on standard in rather than through some
decoded URL.

So I know I might be jumping out of the immediate frame of discussion,
but is extending gopher to do these types of things worth it, or is
that really what the web is for?

-- 
David Allen
http://opop.nols.com/
----------------------------------------
People demand freedom of speech to make up
for the freedom of thought which they avoid.
        --- Soren Aabye Kierkegaard (1813-1855)