[spec] The Tragedy of &
gmym at coopdot.com
Fri Jan 29 12:05:31 GMT 2021
Gary Johnson <lambdatronic at disroot.org> wrote
> => form?$SESSION&name Name: $NAME
> => form?$SESSION&password Password: $PASSWORD
> => form?$SESSION&smog SMOG is great: $SMOG
> => form?$SESSION&plant Best Astrobotany Plant: $PLANT
> => form?$SESSION&submit Submit Answers
(Obviously, a more robust state management mechanism could be achieved
> with client certs and a DB, but I just mean to show a very simple
> example here.)
Yes, if the client supports client certificates, we can skip sending
$SESSION and use the regular inputs:
```text/gemini list of links
=> gemini://awesome.capsule.net/form/name Name
=> gemini://awesome.capsule.net/form/password Password
=> gemini://awesome.capsule.net/form/smog SMOG is great
=> gemini://awesome.capsule.net/form/plant Best Astrobotany Plant
=> gemini://awesome.capsule.net/form/submit Submit Answers
## Section 3.3: (DESIRED) Client-side Requests
> The intention of this example is that the clients would produce requests
> of this form after each input prompt:
> => gemini://awesome.capsule.net/form?$SESSION&name&Gary%20Johnson
> => gemini://awesome.capsule.net/form?$SESSION&password&secret
> => gemini://awesome.capsule.net/form?$SESSION&smog&yes
> => gemini://awesome.capsule.net/form?$SESSION&plant&Ficus
> where $SESSION is whatever value was generated by the CGI script on the
> first page load.
I do not understand this example.
When using regular inputs, the client will send these requests:
(No "?" on "submit" since it's just telling the server that we're done.)
What is the benefit of doing it your way?
## Section 3.4: Server-side State Management and Form Submission
> With this information in the query params, it would be easy to store a
> lookup table in the CGI script that mapped session -> field -> value,
> and these values can then be easily inserted into the original Gemtext
> template form above (see Section 3.1) in response to these requests.
If you format the URLs like this:
...then $FIELD should show up as PATH_INFO (probably with a leading "/")
and $VALUE as QUERY_STRING.
The only problem I'm running into here is that the various Gemini
clients I've tested (elpher, bombadillo, kristall) don't actually append
> a user's input as an additional parameter to an existing query string if
> one is present. Instead, bombadillo and kristall just overwrite the
> existing query string and only return ?$NEW_INPUT. Elpher, on the other
> hand, just creates invalid URLs by simply appending ?$NEW_INPUT to
> whatever is already in the URL (e.g.,
> gemini://awesome.capsule.net/form?$SESSION&smog?yes. Neither of these
> behaviors do what I'd want or expect here.
Elpher is doing something weird here but the others are handling inputs as
## Section 4.1: Check the Spec!
> I think the culprit then is probably Gemini Protocol Specification
> section 3.2.1 1x (INPUT):
## 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.
Otherwise, we really have no way to input more than one query param
> (with &) other than asking the user to type it directly into the INPUT
> prompt (e.g., cat&dog&pig).
The responsibility for collecting parameters fall on the server, not on the
client. The only thing the client needs to do is sending one query for each
I'm hoping this isn't the spec's intention
> here and that we just have a case of ambiguous wording that has led some
> client authors to create divergent (or broken) implementations
Sorry to disappoint you. I suggest leaving the ampersands to the web
I've attached a short (47 line) CGI script (for Space Age) that
> implements the dynamic form example described in this email.
Thank you for providing example code and I'm sorry for not doing the same.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gemini