On Tue Dec 22, 2020 at 9:34 PM CET, John Cowan wrote: Given the potential for "what should fragments mean/do in Gemini?" to turn into yet another endless discussion, and given their relatively low importance (Gopher has survived without them for 30 years and I, personally, don't remember ever really missing them in that context), I'm tempted to take quite seriously Petite Abeille's suggestion to simply remove them entirely. However, for the sake of responding coherently to other issues raised in this thread, let's suppose fragments hang around: > 1) Clients MUST NOT send a fragment to the server. I agree with this, and would be happy to make it explicit in the spec. > 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. This I'm not so clear on. If a server receives a request for a URL which doesn't include a fragment (which everybody seems to agree is how things should work), why on Earth would it want to redirect to a URL which *does* have a fragment? The only case I can think of where this might be useful is if multiple separate documents were merged into a single document, with fragments pointing to the distinct subsections which used to stand alone. That's neat, but is it so important that we should support it instead of doing the brutually simple thing of just saying that redirect URLs, like request URLs, should not include fragments, and that following a redirect involves completely discarding the previous URL (including fragments)? Carrying stuff across between distinct requests feels a bit ugly to me. Cheers, Solderpunk
---
Previous in thread (17 of 27): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)
Next in thread (19 of 27): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)