Questions on INPUT behavior

[Michael Lazar]

Jason McBrayer wrote:
> solderpunk writes:
> >> > 5. In the above example, what happens if a request to that URL
> >> > returns a status code of 10? Should the client strip the existing
> >> > query components from the URL, or append a new key=value pair to
> >> > the end?
> >
> > Hmm. If a client requests the URL above, it should include the query
> > string in the request. So why would the server respond with a status
> > 10 in that case? I mean, it's currently not prohibited in the spec for
> > a server to do that, so this is a fair question. I'm not sure whether
> > we *should* forbid it or spec some sensible client response. Did you
> > have a use case in mind or are you just keeping an eye out for edge
> > cases?
>
> I can imagine a client asking successive questions in response to
> answers. But I'm not sure what the client should do. We might want to
> specify that Gemini URLs should not contain query parts except in
> requests initiated by 1x responses. Or that the query part should never
> be significant in a published URL; that it should be a pre-filled
> suggestion that can be modified by the client.

Here's the example that I was thinking about when I wrote this question. I have
a gopher site that acts as a search engine for drink recipes [1]. Users can
filter their search results based on predefined tags, or they can search by
keyword using a gopher menu "7" query.

After adding some search filters, your path might look like this*:

    gopher://mozz.us:7003/1/search?tag=37&tag=5&image=1

And then if you submit a search to that path, it will append the "q=" param to
the existing filters:

    gopher://mozz.us:7003/1/search?tag=37&tag=5&image=1&q=irish

I'm trying to think of how I could re-implement this type of application in
gemini. And I can't really come up with a good solution if we assume that user
input clears the current query params.

This is admittedly a fringe case and I haven't seen anybody else do this type
of advanced search filtering in gopher. But it's fairly common to use query
params like this in HTTP when designing REST-like endpoints. For example, I
might have a link at the top of my search results that sets
"?limit=20" to control
how many items are returned. I would want the user to be able to submit a new
search string while preserving their previous choice for the limit.

*side note: Many gopher clients can't load this URL directly because they
incorrectly treat everything after the "?" as a search query, or they strip it
off completely (I'm looking at you, lynx!) [2].

[1] gopher://mozz.us:7003/1/search
[2] https://www.w3.org/Addressing/URL/4_1_Gopher+.html

- mozz