Hi all,
Piggybacking on the recent threads about forms in gemini, how should
we be handling errors with input validation? I've run into this
problem a few times already with astrobotany and I haven't found a
great solution for it yet.
REQUEST : gemini://example.com/page/input
RESPONSE : 10 Enter a choice [yes/no]
REQUEST : gemini://example.com/page/input?potato
RESPONSE : ???
---
Option 1.
Return a proper error response code.
REQUEST : gemini://example.com/page/input?potato
RESPONSE : 59 Invalid choice (potato)
Pros
- Feels like the semantically correct thing to do.
Cons
- Many gemini clients don't display the human readable meta along
the error codes (For consistency, I guess?). This results in a
terribly confusing user experience.
---
Option 2.
Return a new input prompt with the error message included.
REQUEST : gemini://example.com/page/input?potato
RESPONSE : 10 Invalid choice (potato). Enter a choice [yes/no]
Pros
- Convenient for the user.
- The UI is reasonably clean.
Cons
- It can get ugly really quickly with longer error messages being
concatenated on the same line as the original prompt.
---
Option 3.
Return a successful response with the error as plain text.
REQUEST : gemini://example.com/page/input?potato
RESPONSE : 20 text/gemini
Invalid option (potato).
Pros
- Will always display the error message to the user.
Cons
- No semantic indication that there was an error.
- Can screw up browser history.
---
I know it's blasphemy but a new error code could be really nice here.
Something like
54 INVALID INPUT
Indicates that the query string contained a value that was not
accepted by the server. The <meta> should be a human-readable
error message that will be shown to the user. Sophisticated clients
can display the error message along with re-prompting the user with
the same input from the previous request.
Any thoughts or other ideas?
- Michael
It was thus said that the Great Michael Lazar once stated: > > I know it's blasphemy but a new error code could be really nice here. No it's not. This is a real need that has come up from experience with the protocol. > Something like > > 54 INVALID INPUT > Indicates that the query string contained a value that was not > accepted by the server. The <meta> should be a human-readable > error message that will be shown to the user. Sophisticated clients > can display the error message along with re-prompting the user with > the same input from the previous request. > > Any thoughts or other ideas? I like it and agree that it should be adopted. -spc
---
Previous Thread: Gemini Digest, Vol 18, Issue 58
Next Thread: [users] [announce] geminispace.info - alternative search provider