[spec] What to do of fragments when there is a redirection

[Nathan Galt]

> On Dec 22, 2020, at 3:20 PM, Luke Emmet <luke at marmaladefoo.com> wrote:
> 
> 
> 
> On 22-Dec-2020 20:34, John Cowan wrote:
>> 
>>    Therefore, for HTTP, RFC 7231 has to describe in detail what the
>>    client ("user agent", in HTTP parlance) has to do with
>>    fragments. Should we consider that "in doubt, do as HTTP does?")
>> 
>> 
>> I think we should adopt the following RFC 7231 compatible rules.
>> 
>> 0) The semantics of a fragment are defined solely by the media type of the resource and not by the rest of the URL.
>> 
>> 1) Clients MUST NOT send a fragment to the server.  If the server needs to know the content of a fragment, it should be part of the path or the query string instead.  This was a firm HTTP rule until fragments beginning with ! were invented, and IMO should be a firm Gemini rule.
>> 
>> 2) If the client gets a redirect containing a fragment, the client MUST apply this fragment when the redirected resource is retrieved, ignoring any original fragment.
>> 
>> 3) If the original URL has a fragment and the redirect doesn't, the client MUST apply the original fragment when the redirected resource is retrieved.
>> 
>> 4) Content authors MUST NOT put personally identifying information into fragments, as they can be transferred from one host to another by the operation of rule 3.
> 
> I agree with this - that they should be client side only, but can be part of a persistent URL.
> 
> The question that remains particularly, is what should be the semantics of the fragment for our most prevalent media type - text/gemini?
> 
> I would propose that the fragment should indicate an offset to one of the headers in the page - but we'd need to agree how they should be formulated.
> 
> Some Markdown engines seems to have an established convention of creating the fragment name based on the header text, suitably normalised, e.g.
> 
> # Here is a heading
> 
> would have the associated offset fragment: "here-is-a-heading"
> 
> this approach is somewhat robust to page edits
> 
> Another approach could be to use the line index e.g. endpoint#12 means the twelfth line in that page. This is more finegrained, but is a bit more fragile.
> 
> Then again, do we really have much of a need to do page-specific indexing for URLs? Most Gemini pages are quite simple and not too complicated. So maybe we just get by without the fragment?
> 
> - Luke

Chrome also supports text fragments like `#:~:text=an%20example%20text%20fragment` , and they’re trying to have this feature be a proper web standard. No other browser has bothered implementing it, though.

https://wicg.github.io/scroll-to-text-fragment/

PDFs also support `#page=42`.

https://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html