💾 Archived View for gemi.dev › gemini-mailing-list › 001057.gmi captured on 2024-03-21 at 18:16:35. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I am writing a REST API for Gemini and need to have more than one status code coupled with a response body (to parallel the 409 response in Convergence's Notary protocol [1]). Only 2x status codes allow for response bodies, and the only defined 2x status code is 20. No problem, I thought. The second digit is optional, so gemini clients and libraries should accept any 2x status code and treat unknown ones as 20. Right? Well, not in practice. The clients I tested treat the request as failed if the status code begins with 2 but is anything other then 20. Let's clarify what the behavior of clients ought to be. I think this makes the most sense:
Sorry if I'm missing something but is this not already clearly set out in the spec? > A client SHOULD deal with undefined status codes > between '10' and '69' per the default action of the initial digit. So a > status of '14' should be acted upon as if the client received a '10'; a > status of '22' should be acted upon as if the client received a '20'.
On Tue, 2021-10-26, Alan wrote: > Sorry if I'm missing something but is this not already clearly set out > in the spec? > >> A client SHOULD deal with undefined status codes >> between '10' and '69' per the default action of the initial digit. So a >> status of '14' should be acted upon as if the client received a '10'; a >> status of '22' should be acted upon as if the client received a '20'. Ah, you're right, Sean took care of this [1]. Completely missed it. This text is not on gemini.circumlunar.space, though. Developers, take note. https://gitlab.com/gemini-specification/protocol/-/blob/master/specification.gmi#L229
---
Previous Thread: A proposal to freeze the Gemini specification