Questions on INPUT behavior

[Sean Conner]

It was thus said that the Great Michael Lazar once stated:
> Hi all. I'm looking into implementing a few endpoints on my server that accept
> user input, and I ended up with a few ambiguities about the gemini specification
> that I would like to discuss:
> 
> ```
> The requested resource accepts a line of textual user input.
> The <META> line is a prompt which should be displayed to the
> user.  The same resource should then be requested again with
> the user's input included as a query component.  Queries are
> included in requests as per the usual generic URL definition
> in RFC3986, i.e. separated from the path by a ?.  There is no
> response body.
> ```

  I think that should read "there is no request body"---the response can
include content, dependent upon the status code.

> Here are my questions:
> 
> 1. Should the query component be formatted as a "key=value" parameter?
>    Or should it be added directly as the entire query component?
> 
>    A. "gemini://hostname.com/input?q=AbrahamLincoln"
>    vs.
>    B. "gemini://hostname.com/input?AbrahamLincoln"

  B, unless there's a way to designate the variable name (which I did
suggest to solderpunk---perhaps I should float it here).

> 2. Should the query component allow percent-sign escaping?
>    If so, which characters should be escaped?
> 
>    A. "gemini://hostname.com/input?Hello%20world"
>    vs.
>    B. "gemini://hostname.com/input?Hello world"

  The following characters in the query should be escaped:

	SPACE # % < > [ \ ] ^ { | } "

and unless you are sending name/value pairs, 

	= &

should also be escaped (this per RFC-3986).

> 3. Should a server be allowed to link to a URL with the user input pre-filled?
>    E.g. Should this link, if placed in a text/gemini file, mean the same thing
>    as the user manually typing in "Hello World"?
> 
>    A. "=>/input?Hello%20world"

  I don't see why not.

	gemini://gemini.conman.org/cgi?Hello%20World

(this link works, by the way---although it's just a sample CGI script)

> 4. If my server has an endpoint that does not request user input, can I
>    re-purpose the query section for my own needs?
> 
>    A. "gemini://hostname.com/items?page=2&limit=20"

  Again, I don't see why not.  The query string is part of a URL, and
clients send URLs so this should be an issue client side.  What the server
side does with the query is up to the server.

> 5. In the above example, what happens if a request to that URL returns a status
>    code of 10? Should the client strip the existing query components from the
>    URL, or append a new key=value pair to the end?

  That's a good question and one I do not have an answer to.

> 6. What widget should the client use to display the input prompt? A single line
>    input, or a multi-line text box? Should newline characters even be allowed?

  It would depend upon the client.  I think the expectation is a single line
input, but I can see a multi-line box being useful as well.  

> 7. Should there be a maximum input length? Currently it is implicitly defined
>    as 1024 bytes minus the length of the URL.
> 
> Personally, I have mixed feelings about gemini enabling user input in the first
> place. I know that gopher supports it using the "7" item type, but I have only
> seen a couple of compelling use cases for this in the wild. On the other hand,
> it opens up a Pandora's box of complexity by allowing creative developers to
> port over many features from HTTP.

  True, and I've moved quite a few of my web-based projects to both Gemini
[1] and Gopher.

> I can already envision XSS style attacks. For example, say a gemini page
> requests user input that will be rendered in a public text/gemini page like a
> guestbook. The bad-actor submits a message that contains something like:
> 
>     "\n=>http://malicious.url\thttp://innocent.url".
> 
> Servers will need to be diligent in sanitizing their inputs, which kind of sucks
> for what should be a simple protocol.

  Experiement---point your favorite terminal based gopher client here:

	gopher://verisimilitudes.net/02019-08-18.ecma-48&utf-8	or
	gopher://verisimilitudes.net/02019-08-18.ecma-48%26utf-8

  This page directly embeds ECMA-48 escape sequences (aka ANSI escape codes)
in the text---what does your favorite terminal based gopher client do?  Does
it send the raw codes directly to the terminai?  Does it filter them out
entirely?  Does it show them? [2]

  Also, there's nothing that says a server *has* to support user input.

  -spc (

[1]	I even created a CGI interface to my Gemini server, and it can even
	translate HTTP status codes to Gemini ones.

[2]	My own gopher client (not yet published) does filter out escape
	sequences and not because of this page---it was a deliberate design
	choice I made when writing after doing a very deep dive into ECMA-48
	in the past year or two.