A client SHOULD NOT send the fragment part of a URL to the server?



On 09-Jun-2020 21:00, solderpunk wrote:
> On Tue, Jun 09, 2020 at 09:46:56PM +0200, Petite Abeille wrote:
>> "A client SHOULD NOT send the fragment part of a URL to the server."
>> -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01
>> https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002
>>
>> Such restriction is not reflected in the spec itself.
>>
>> At the same time, the spec mentions header lines as "machine-readable 
representation of the internal structure of the document".
>>
>> Could one reflect such structure using fragments?
>>
>> E.g.:
>>
>> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types
>>
>> Part of the gemini canon?
> It's certainly something people have suggested.  I guess to make it work
> reliably would require a very strict specification of how to transform
> headings into fragments, which sounds fiddly and dull...
>
> Either that, or we allow just numeric fragments like 3.2, which the
> client is supposed to map to the second subsection of the third section.
>

The canonical way to do this in Markdown (and more widely on the web) 
seems to be lowercase kebab case of the alphabetic content, with single 
hyphens

So it would be

gemini://gemini.circumlunar.space/docs/specification.gm#core-line-types

This is much more robust than having an offset index like 3.2, which will 
break all the links if you add a new section 1 to the page. I will 
probably implement this scheme in GemiNaut when I get round to it. The 
case insensitivity means you can change your mind about title casing on 
the heading and things still generally work fine.

I think the behaviour can be the same as on the web where the fragment 
behaviour degrades well. If there is no such fragment, or the client does 
not support them, there is no scrolling to the offset.

I think it is just a matter for the client authors to agree on (where they 
implement it). If it is in the spec, or accompanying guidance that might 
be nice, but not essential at the moment.

Best wishes

  - Luke

---

Previous in thread (8 of 12): 🗣️ Felix Queißner (felix (a) masterq32.de)

Next in thread (10 of 12): 🗣️ solderpunk (solderpunk (a) SDF.ORG)

View entire thread.