CGI programs and the gemini protocol

[Philip Linde]

I don't see how it's how it's underspecified. In particular, I don't
see why anyone should assume &-separated values. The spec refers to
IETF RFC 3986, which doesn't at all concern how to encode multiple
values. It simple describes the query as a segment of a URI starting
with a "?" and ending with the end of the URI or a fragment marker
"#".

The spec makes it clear that the input should be included as a query
component. There can only be one RFC 3986 query component. Possibly
calling it *the* query component instead would be a useful
clarification for people who are not so familiar with RFC 3986.

If a server wants to produce a e.g. a form with multiple input
queries, accumulating a form state throughout, they can encode the
state of the completed parts of the form in the path segment and serve
a redirect after each input.

If this is a new feature that people want, I think it should be
discussed as such. To say that it's underspecified is however just
wishful thinking.

--
Philip

On 3/20/21, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Frank Jüdes once stated:
>> Hi fellow Geminauts,
>>
>> i am fairly new to the gemini protocol, but already like the simplicity
>> of everything, compared to the complexity of "modern" websites.
>>
>> Currently i am using the Jetforce server and several clients (Kristal,
>> Lagrange, Geminaut) and trying to wrap my head around the /input/
>> status-code:
>>
>>  * Upon first invocation my cgi-script figures out that the
>>    /QUERY_STRING/ is empty and responds with /10 Please enter some data/
>>  * The client is prompting for some data and re-requesting the URL with
>>    the data attached: [URL]?Some Data
>>  * My CGI program detects that there is some data in the URL and
>>    responds with /10 Please enter some more data/
>>  * Upon which the client asks me to enter some more data and
>>    re-requests the URL, but only with the /some more data/ attached to
>>    the URL
>>    The data that was already attached to the URL will be replaced with
>>    the new data.
>>
>> Is that the intended functionality?
>>
>> It is only possible to use one parameter?
>
>   It's underspecified, and it's a current issue:
>
> 	https://gitlab.com/gemini-specification/protocol/-/issues/19
>
>> That definitely would make parsing the URL somewhat easier, but would
>> require some creativity in the CGI if more than one parameter is needed.
>
>   Yes, and it depends upon the quality of implementation of the CGI spec.
>
>> Can somebody please explain this to me in a nutshell? Thank you very
>> much in advance for your help.
>
>   Unfortunately, it's an open issue.  I'm [1] leaning towards appending the
> new output (option #2 on the issue) but the spec needs to be updated first.
>
>   -spc
>
> [1]	Disclaimer:  speaking with my BDFLA [2] hat here.
>
> [2]	Benevelent Dictator For Life's Assistant.
>
>