💾 Archived View for gemi.dev › gemini-mailing-list › 001068.gmi captured on 2023-11-04 at 13:18:21. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

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

[ANN] Specification update (v 0.16.0)

Solderpunk <solderpunk (a) posteo.net>

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

Link to individual message.

almaember <almaember (a) disroot.org>

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

Link to individual message.

Justin Abrahms <justin (a) abrah.ms>

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

Link to individual message.

Philip Linde <linde.philip (a) gmail.com>

On Sun, 14 Nov 2021 23:03:01 +0100
almaember <almaember at 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

Link to individual message.

PJ vM <pjvm742 (a) disroot.org>

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

Link to individual message.

---

Previous Thread: Uploading content over gemini

Next Thread: Haskell Gemini server framework