💾 Archived View for rawtext.club › ~sloum › geminilist › 004958.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Katarina Eriksson 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:
> 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: gemini://awesome.capsule.net/form/name?Gary%Johnsongemini://awesome.capsule.net/form/password?secretgemini://awesome.capsule.net/form/smog?yesgemini://awesome.capsule.net/form/plant?Ficusgemini://awesome.capsule.net/form/submit (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: gemini://$HOST/path/to/script/$FIELD?$VALUE ...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 asintended. ## 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 theclient. The only thing the client needs to do is sending one query for eachfield. 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 webqueries. [...] 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. -- Katarina >-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210129/c5136798/attachment.htm>