On Wed, Aug 28, 2019 at 11:59 AM Sean Conner <sean at conman.org> wrote:
> Wait a second ... I thought gopher URLs don't support the query type.
> It's not mentioned at all in RFC-4266 (and there are no updates as far as I
> can see).
>From RFC-4266:
<selector> is the Gopher selector string. In the Gopher protocol,
Gopher selector strings are a sequence of octets that may contain any
octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal
(US-ASCII character LF), and 0D (US-ASCII character CR).
Aside for those 3 reserved octets, you can stick anything you want in the
selector part of the URL. Query string don't have any special meaning to
gopher, they're just additional bytes in the selector that get sent to the
server.
>> 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.
>
> Add on to the path component? I did a very short version of that for my
> guessing game:
This would lead to a bunch of different paths that point to the same resource:
/search/tag_37/tag_5/image_1/
/search/tag_5/tag_37/image_1/
/search/image_1/tag_5/tag_37/
...
Of course, I could write my server to be able to understand and parse these
path components. But it throws the whole "path as a hierarchy" paradigm out
the window. I can only assume that this issue is why query param key-value
pairs were invented in the first place.
- mozz
---
Previous in thread (9 of 16): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (11 of 16): 🗣️ julienXX (julien (a) sideburns.eu)