💾 Archived View for rawtext.club › ~sloum › geminilist › 006517.gmi captured on 2024-02-05 at 10:58:59. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[tech] Client history behavior with redirects

Michael Lazar lazar.michael22 at gmail.com

Mon May 17 17:49:43 BST 2021

- - - - - - - - - - - - - - - - - - -

Hi all,

I have a question on a common design pattern in gemini. Say we havea guestbook, message board, etc. that accepts user comments via aninput query. A normal session with a client might look like this:


C: /guestbookS: 20 text/gemini (display the guestbook page)

C: /guestbook/inputS: 10 enter your message

C: /guestbook/input?hello%20worldS: 30 /guestbook (submit the user's message and redirect)

C: /guestbookS: 20 text/gemini (display the guestbook page)```

Now, what should happen at this point when the user clicks the"back" button in their client?

A. The client resubmits "/guestbook/input?hello%20world". This is not   desired because it will result in double posting the message. This   same problem is solved on the web using the Post/Redirect/Get   pattern [1]. I suppose the gemini equivalent would be "don't store   requests that return 3x in the client's history". With this rule,   queries like GUS searches would still be cached because   "gemini://geminispace.info/search?hello" returns a 20 response.

B. The client re-prompts the user with "enter your message". I've   seen a few (most?) clients do this and it's a pretty jarring   experience as a user, because I did not click on a link first   to prime the input prompt. IMO we should also make a rule "don't   store requests that return a 1x in the client's history". There's   no web equivalent for this that I could find.

C. The client loads "/", which is the latest cached request before   the current page. This seems like the desired behavior to me.

Thoughts?

- Michael

[1] https://en.wikipedia.org/wiki/Post/Redirect/Get