💾 Archived View for rawtext.club › ~sloum › geminilist › 004965.gmi captured on 2024-03-21 at 16:46:40. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[spec] The Tragedy of &

Chris Babcock cbabcock at asciiking.com

Sat Jan 30 22:19:25 GMT 2021

- - - - - - - - - - - - - - - - - - -

This is going to be weird, because I disagree with almost everything you've said except that appending the query string should be guaranteed. I hope this is helpful

January 30, 2021 1:54 PM, "Gary Johnson" <lambdatronic at disroot.org> wrote:

The issue I'm raising is that there appears to be no way to pass more

than one piece of information at a time in our query strings. This has a

very significant impact on any writers of CGI scripts, which is how many

Gemini servers allow users to add dynamic pages to their capsules.

But why, you ask?

Because each CGI script is available at a particular file path and

therefore additional path segments can't be used to pass information to

them. They have to get their inputs from the query string.

%< ------------------------------

This would make a form with N fields require N+1 separate CGI scripts,> all chained together via links that represent the directory structure

into which they are installed.

This is an absolute nightmare scenario for programming anything that

wants to accept user inputs.

Well, you *could* pass extra path info to the script... So, the script at cgi-bin/index.cgi handles all cgi-bin/* and treats the path after cgi-bin as positional arguments

So what does this mean for Geminispace?

It means essentially that CGI scripts are currently second-class

citizens, and the only people who can write dynamic capsules are server

authors (or people willing to hack on server code). This is because

encoding information using path segments requires injecting custom

routing table code into the server's request handler.

CGI scripts *are* second class citizens in Gemini, but it's because the UX and dev-op experience of line based input is terrible. The fact that a static routing table is more performant and has a better security profile than parsing the path info dynamically is less relevant than the fact that this is a line based protocol

%< ------------------------------

> ## Section 4.2: Append Don't Replace!

As far as I can tell, the fix here is for Solderpunk to update the text

in section 3.2.1 to indicate that if a query string is already part of

the request leading to an INPUT response, then the user's input should

be appended (using &) to the existing query string rather than replacing

it wholesale (using ?).

This is not a necessary spec change.

Yes, it really is if anyone other than server authors is ever going to

be able to write their own dynamic pages.

Now, "Append, don't replace," is a reasonable expectation to make of clients and it's still useful for the devops situation, even if it's not *strictly* necessary

%< ------------------------------ > If you can write a CGI script that can correctly associate INPUT

responses with their intended variables, please share it. I suspect it

would be quite educational.

The two alternatives to requiring clients to preserve collected state in the query parameter are to save state in the CGI script or to pass positional arguments via the path. I think append is reasonable. It also preserves principle of least surprise and other desirable qualities

CGI *is* going to be second class in Gemini as long as forms aren't an option, but that's a consequence of the decision to support line-based clients. Appending the query doesn't do violence to that design

Chris