💾 Archived View for lists.flounder.online › gemini › threads › cc3820f73c834ec7aaa7c4d4e3c95aef@post… captured on 2022-07-16 at 16:21:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: solderpunk@posteo.net
Date: Sun, 14 Nov 2021 18:11:46 +0000
Message-Id: cc3820f73c834ec7aaa7c4d4e3c95aef@posteo.net
To: "Gemini application layer protocol" <gemini@lists.orbitalfox.eu>
--------------------------------------
Hi folks,
I have just pushed another set of small updates to the specification.
In addition to assorted spelling and grammar fixes, and clarifying that keywords MUST, SHOULD etc. should be interpreted against BCP14, there are two substantive changes.
The first is that the specification is now explicit about what to do in the event that a request including a query component receives a 3x redirect status code in response: the redirect URL should be used as is, and the client should not apply the original request's query to the redirect URL. If you are the author of a client which *does* modify redirect URLs in this way, you need to change this behaviour in order to be spec compliant.
The second is that the specification now explicitly forbids the use of Unicode byte order marks (BOMs) in either Gemini requests or Gemini response headers. If your client or server includes a BOM in these places, you should stop doing that. There will be a future update dealing with the use of BOMs in Gemini response bodies as well, but the changes I just pushed affect only response headers.
Chances are very good nobody actually needs to make any changes to code as a result of these updates.
Cheers,
Solderpunk
From: almaember@disroot.org
Date: Sun, 14 Nov 2021 23:03:01 +0100
Message-Id: f39373e7-76b6-1f61-2030-3fe411deb368@disroot.org
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: cc3820f73c834ec7aaa7c4d4e3c95aef@posteo.net
--------------------------------------
Hey!
Good to see progress being made towards finalisation. Hopefully the spec will be final soon!
The first is that the specification is now explicit about what to do in > the event that a request including a query component receives a 3x > redirect status code in response: the redirect URL should be used as is, > and the client should not apply the original request's query to the > redirect URL. If you are the author of a client which *does* modify > redirect URLs in this way, you need to change this behaviour in order to > be spec compliant.
Could you please elaborate on what "apply the original request's query to the redirect URL" means? I'm not sure what this forbids.
The second is that the specification now explicitly forbids the use of > Unicode byte order marks (BOMs) in either Gemini requests or Gemini > response headers. If your client or server includes a BOM in these > places, you should stop doing that. There will be a future update > dealing with the use of BOMs in Gemini response bodies as well, but the > changes I just pushed affect only response headers.
This would only apply to text/gemini, right? So not any arbitrary Unicode document (possibly under UTF-16 or UCS encodings)?
But welcome change anyway. BOMs suck!
Cheers,
almaember
From: justin@abrah.ms
Date: Sun, 14 Nov 2021 15:51:34 -0800
Message-Id: 0b92940e-2e28-45a5-9251-535e068a136a@www.fastmail.com
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: cc3820f73c834ec7aaa7c4d4e3c95aef@posteo.net
--------------------------------------
JJnnnñ I'm v
Iphone
Up Hohlbonbons b v I'll jump kkkmm I'll nothing tvy
On Sun, Nov 14, 2021, at 10:11 AM, Solderpunk wrote:
Hi folks,
I have just pushed another set of small updates to the specification.
In addition to assorted spelling and grammar fixes, and clarifying that
keywords MUST, SHOULD etc. should be interpreted against BCP14, there
are two substantive changes.
The first is that the specification is now explicit about what to do in
the event that a request including a query component receives a 3x
redirect status code in response: the redirect URL should be used as is,
and the client should not apply the original request's query to the
redirect URL. If you are the author of a client which *does* modify
redirect URLs in this way, you need to change this behaviour in order to
be spec compliant.
The second is that the specification now explicitly forbids the use of
Unicode byte order marks (BOMs) in either Gemini requests or Gemini
response headers. If your client or server includes a BOM in these
places, you should stop doing that. There will be a future update
dealing with the use of BOMs in Gemini response bodies as well, but the
changes I just pushed affect only response headers.
Chances are very good nobody actually needs to make any changes to code
as a result of these updates.
Cheers,
Solderpunk
From: linde.philip@gmail.com
Date: Mon, 15 Nov 2021 02:52:10 +0100
Message-Id: 20211115025210.2c42a55ecfd672efaafef102@gmail.com
To: <gemini@lists.orbitalfox.eu>
In-Reply-To: f39373e7-76b6-1f61-2030-3fe411deb368@disroot.org
--------------------------------------
On Sun, 14 Nov 2021 23:03:01 +0100
almaember <almaember@disroot.org> wrote:
Could you please elaborate on what "apply the original request's query
to the redirect URL" means? I'm not sure what this forbids.
Basically, from what I understand
c: gemini://example.com/?querystring
s: 30 /movedhere
c (redirecting): gemini://example.com/movedhere?querystring
is now explicitly forbidden. The client should drop the query string
following the redirect and use the redirect URL directly:
c: gemini://example.com/?querystring
s: 30 /movedhere
c (redirecting): gemini://example.com/movedhere
The query string can still carry over, but it's up to the server, which
has to be explicit about it:
c: gemini://example.com/?querystring
s: 30 /movedhere?querystring
c (redirecting): gemini://example.com/movedhere?querystring
--
Philip
From: pjvm742@disroot.org
Date: Tue, 23 Nov 2021 23:14:04 +0000
Message-Id: YZ11vPOPp/ayNEqo@zee
To: "almaember" <almaember@disroot.org>
In-Reply-To: f39373e7-76b6-1f61-2030-3fe411deb368@disroot.org
Cc: "Gemini ML" <gemini@lists.orbitalfox.eu>
--------------------------------------
On Sun, Nov 14, 2021 at 11:03:01PM +0100, almaember wrote:
This would only apply to text/gemini, right? So not any arbitrary Unicode
document (possibly under UTF-16 or UCS encodings)?
Solderpunk notes that the present decision only deals with BOMs in the
--
pjvm