[tech] Client history behavior with redirects

Hi all,

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

 ```
C: /
S: 20 text/gemini (display the home page)

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

C: /guestbook/input
S: 10 enter your message

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

C: /guestbook
S: 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

Hi Michael,

first thing is that every gemini-site should avoid to put the user into a 
situation where the "back" button is the only way out, by providing arbitrary links.

And i agree with you, option "c" looks like what i would expect to see 
when clicking on the "back" button.

Another option is to give the end-user the choice of where back in the 
history to go, like if you right-click on the "back" button in the chromium browser.

Best regards from Charleston (WV),
     Frank/2

On 2021-05-17 12:49, Michael Lazar wrote:
> Hi all,
> 
> I have a question on a common design pattern in gemini. Say we have
> a guestbook, message board, etc. that accepts user comments via an
> input query. A normal session with a client might look like this:
> 
> ```
> C: /
> S: 20 text/gemini (display the home page)
> 
> C: /guestbook
> S: 20 text/gemini (display the guestbook page)
> 
> C: /guestbook/input
> S: 10 enter your message
> 
> C: /guestbook/input?hello%20world
> S: 30 /guestbook (submit the user's message and redirect)
> 
> C: /guestbook
> S: 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
-- ------------------------------------------------------------------------
My Gemini Capsule's orbit is gemini://h2903872.stratoserver.net
------------------------------------------------------------------------

On Mon, 17 May 2021 at 18:02, Frank Jüdes
<Frank.Juedes@linux4specialists.com> wrote:
>
> Hi Michael,
>
> first thing is that every gemini-site should avoid to put the user into 
a situation where the "back" button is the only way out, by providing arbitrary links.
>

I disagree with this, there are many times I don't want to add a back
link, and it's not always possible if you have non-gemtext content.
A hard-coded "back" link is flawed anyways, as the server has no clue
where the user came from. It can only be an "up" link or go to the
most common place that this page is linked from.

-Oliver Simmons

On Mon, 17 May 2021 at 17:50, Michael Lazar <lazar.michael22@gmail.com> wrote:
>
> Hi all,
>
> I have a question on a common design pattern in gemini. Say we have
> a guestbook, message board, etc. that accepts user comments via an
> input query. A normal session with a client might look like this:
>
> ```
> C: /
> S: 20 text/gemini (display the home page)
>
> C: /guestbook
> S: 20 text/gemini (display the guestbook page)
>
> C: /guestbook/input
> S: 10 enter your message
>
> C: /guestbook/input?hello%20world
> S: 30 /guestbook (submit the user's message and redirect)
>
> C: /guestbook
> S: 20 text/gemini (display the guestbook page)
> ```
>
> Now, what should happen at this point when the user clicks the
> "back" button in their client?
>
> ⚞snip⚟

The way I would like it is:
 ```
C: /
S: 20 text/gemini (display the home page)
Stored in history

C: /guestbook
S: 20 text/gemini (display the guestbook page)
Stored in history

C: /guestbook/input
S: 10 enter your message
Not stored due to it being an input (resp. code 1x)

C: /guestbook/input?hello%20world
S: 30 /guestbook (submit the user's message and redirect)
Redirect not stored, the page redirected to should be stored (resp. code 3x)

C: /guestbook
S: 20 text/gemini (display the guestbook page)
Stored in history. It's a duplicate of the previous page in history
though, so it should probably be removed.
 ```

That is, response codes 1x and 3x aren't stored in history, and
duplicates of the same URI (including query!) in history are merged
into one.
It's not the query that makes it not store, it'd be the response code.
So if /guestbook/input?hello%20world gave a 20 response code instead
it would be stored, as that's likely a unique page e.g. search results
or generated content.

This shouldn't be required behaviour, it'd be a "best practice"
recommendation instead.
Different browsers have different preferences and in an ideal world
this would be configurable by settings.

-Oliver Simmons

On Mon, May 17, 2021 at 12:49:43PM -0400,
 Michael Lazar <lazar.michael22@gmail.com> wrote 
 a message of 49 lines which said:

> 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.

I just tested with Lagrange and the bulletin board
<gemini://station.martinrue.com/> and this is the behaviour I get and
I'm fine with it.