Questions on INPUT behavior

[solderpunk]

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

Once the user *submits* their input, the response to *that* request can
of course have any status code and a possible response body, but in that
part of the spec (maybe it's unclear and needs changing) I'm talking
about the response with code 10, which I shouldn't have a body, as it's
just delivering a prompt and the information that this resource wants an
input.

> >    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).

What I had in mind, and what I think most implementations do so far, is
indeed B.  It's possible I coud be convinced otherwise, but I don't
really see the value in speccing a fixed variable named like `q`.  It's
perfectly cromulent according to the URL RFC to use treat the query as a
string.  The key=value pair syntax is common in the web world mostly as
a way to make HTML forms work, and we don't have forms.

I *did* consider a 1x status code whose <META> was some kind of
machine-readable description of a form, but that doesn't degrade nicely
in simple clients which ignore the second status digit, as then the
human user has to imagine the form in their head and type a suitable
response.

>   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).

Yes, this is right.  Remember, Gemini requests are URLs, and we don't
make the rules for URLs, we (hopefully!) follow them.

> >    A. "=>/input?Hello%20world"
> 
>   I don't see why not.
> 
> 	gemini://gemini.conman.org/cgi?Hello%20World
> 

I don't see why not either.

> >    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.

Agreed.

> > 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?

Hmm.  If a client requests the URL above, it should include the query
string in the request.  So why would the server respond with a status 10
in that case?  I mean, it's currently not prohibited in the spec for a
server to do that, so this is a fair question.  I'm not sure whether we
*should* forbid it or spec some sensible client response.  Did you have
a use case in mind or are you just keeping an eye out for edge cases?
 
> > 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.  

Good question, I think I agree with Sean above but I'll think on this...

> > 7. Should there be a maximum input length? Currently it is implicitly defined
> >    as 1024 bytes minus the length of the URL.

Hmm,  Do we think it's useful/worthwhile to spec a shorter explicit
limit?  I guess this is hard to answer without canonical applications of
user input being established...

Answers to all the stuff about inputs, XSS, etc. in the future...thanks
for the good questions!

- Solderpunk