💾 Archived View for gemi.dev › gemini-mailing-list › 000826.gmi captured on 2024-03-21 at 18:07:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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? That definitely would make parsing the URL somewhat easier, but would require some creativity in the CGI if more than one parameter is needed. Can somebody please explain this to me in a nutshell? Thank you very much in advance for your help. Best regards from Charleston (WV), Frank/2 -- ------------------------------------------------------------------------ Frank Jüdes 2814 Four Mile Road Charleston, WV 25312, USA Cell: +1-713-885-4421 ------------------------------------------------------------------------
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.
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. > >
It's underspecified in the way that it breaks from what's the common expectations of how query components work without being explicitly clear on the fact that it does so. I'm onboard with that it might be formally correct, but when I read the spec that was one that confused me. /Hugo On Sat, 2021-03-20 at 01:46 +0100, Philip Linde wrote: > 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
---
Previous Thread: C program to resolve UTF-8 IDNs
Next Thread: [users] [ANN] comitium - a feed aggregator for gemini, gopher, and http