💾 Archived View for gemi.dev › gemini-mailing-list › 000420.gmi captured on 2023-12-28 at 15:46:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
At some point the limit of redirections has apparently been removed from the Gemini specification. I only say this because the client at 185.240.246.12 has been caught in my Redirection From Hell test for some time (a steady pace---I'm not complaining about how fast it's doing it). The specification *used* to have a limit of 5 total redirections. I think that needs to be added back into the specificaiton. -spc
It seems to me that the limit on redirection should be purely a client issue rather than a hardwired part of the spec. Some clients won't want to redirect at all, others will want to retry 1 or 5 or 100 times, depending on what they are being used for. On Mon, Oct 26, 2020 at 9:42 PM Sean Conner <sean at conman.org> wrote: > > At some point the limit of redirections has apparently been removed from > the Gemini specification. I only say this because the client at > 185.240.246.12 has been caught in my Redirection From Hell test for some > time (a steady pace---I'm not complaining about how fast it's doing it). > > The specification *used* to have a limit of 5 total redirections. I > think > that needs to be added back into the specificaiton. > > -spc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/5e6d f582/attachment.htm>
It was thus said that the Great John Cowan once stated: > It seems to me that the limit on redirection should be purely a client > issue rather than a hardwired part of the spec. Some clients won't want to > redirect at all, others will want to retry 1 or 5 or 100 times, depending > on what they are being used for. The original limit was 5. But 9,015 (at the precise moment) is a bit excessive. The limit of 5 was to help prevent the creation URL shortners that are so prevelant on the web. Ah, I see that the limit is now mentioned in the Best Practices document, not the specification. Still, a clent *should* give up redirections past some amount (11,329 as of now). -spc (11430 ... )
A good point. But a well-written Gemini shortener would retrieve the URL it is being asked to shorten and make sure that it is not already a redirection; if so, it can either reject or snap the link (although Gemini redirects are officially temporary, there may be exceptions in practice). On Mon, Oct 26, 2020 at 10:16 PM Sean Conner <sean at conman.org> wrote: > It was thus said that the Great John Cowan once stated: > > It seems to me that the limit on redirection should be purely a client > > issue rather than a hardwired part of the spec. Some clients won't want > to > > redirect at all, others will want to retry 1 or 5 or 100 times, depending > > on what they are being used for. > > The original limit was 5. But 9,015 (at the precise moment) is a bit > excessive. The limit of 5 was to help prevent the creation URL shortners > that are so prevelant on the web. > > Ah, I see that the limit is now mentioned in the Best Practices document, > not the specification. Still, a clent *should* give up redirections past > some amount (11,329 as of now). > > -spc (11430 ... ) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201026/bce0 211e/attachment.htm>
If your test is simulating a faulty server, there's as much responsibility on your code to give some indication of failure as there is on a client to detect the condition. I'd suggest something less than 11,430, were I to be asked. Kevin Sent from phone On Tue, 27 Oct 2020, 02:16 Sean Conner, <sean at conman.org> wrote: > It was thus said that the Great John Cowan once stated: > > It seems to me that the limit on redirection should be purely a client > > issue rather than a hardwired part of the spec. Some clients won't want > to > > redirect at all, others will want to retry 1 or 5 or 100 times, depending > > on what they are being used for. > > The original limit was 5. But 9,015 (at the precise moment) is a bit > excessive. The limit of 5 was to help prevent the creation URL shortners > that are so prevelant on the web. > > Ah, I see that the limit is now mentioned in the Best Practices document, > not the specification. Still, a clent *should* give up redirections past > some amount (11,329 as of now). > > -spc (11430 ... ) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/3066 bbdd/attachment.htm>
On Mon, 26 Oct 2020 21:42:45 -0400 Sean Conner <sean at conman.org> wrote: > The specification *used* to have a limit of 5 total redirections. I think > that needs to be added back into the specificaiton. Perhaps <=5 should be specified. For now, there is at least a recommendation for it in the best practices document: gemini://gemini.circumlunar.space/docs/best-practices.gmi I'm not entirely convinced that automatic redirects are good. Manual redirects that present the users with a link to the redirection target could be unlimited and still make it more obvious to users when they're thrown about. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/9cfa 7f9f/attachment.sig>
On Tue, Oct 27, 2020 at 1:28 PM Philip Linde <linde.philip at gmail.com> wrote: > I'm not entirely convinced that automatic redirects are good. Manual > redirects that present the users with a link to the redirection target > could be unlimited and still make it more obvious to users when they're > thrown about. > Not all clients have human users attached, though. Crawlers and other automated applications need to make their own decisions when to stop. Which reminds me: what is the best thing for such an application to do when it gets a 1x response? John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Heh, heh: ... or three pairs of wheels? I wonder what would have happened if Ravna had just read a little further. In some weird way, Twirlip knows the Secret of the Riders. --Vernor Vinge, note 601 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/d3a8 dfc8/attachment.htm>
On Tue, 27 Oct 2020 13:31:36 -0400 John Cowan <cowan at ccil.org> wrote: > Not all clients have human users attached, though. Crawlers and other > automated applications need to make their own decisions when to stop. Yes, I think its reasonable for a crawler to decide for itself how many redirects it wants to follow, in the same sense that it's reasonable for a user. > Which reminds me: what is the best thing for such an application to do when > it gets a 1x response? To interpret the spec strictly, a client should display the query to the user, and should then request the same resource with the user's input included. This is impossible for a client that doesn't interact with a user, so a crawler should just ignore 1x responses. This seems like the best approach practically as well. There is no set of standard queries that the crawler can safely interpret to mean something it can answer. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/1250 e0f5/attachment.sig>
It was thus said that the Great Kevin Sangeelee once stated: > If your test is simulating a faulty server, It's not so much simulating a faulty server as it is simulating an infinite nymber of redirects. It could possibly be server A -> server B -> server C -> server D -> server E -> server A (repeat). > there's as much responsibility > on your code to give some indication of failure as there is on a client to > detect the condition. How? Given that a redirection loop can exist across servers. > I'd suggest something less than 11,430, were I to be asked. So would I. -spc
It was consequently queried by the Kind and Honourable Sean Conner: How? Given that a redirection loop can exist across servers. > The link '/test/redirhell/' generates some unique hex for each new redirect path, which could alternatively have the hex preserved across redirects, but with a counter that's incremented instead. If the counter exceeds, say 11428, then return a '50 YOU ARE DRIVING ME NUTS' response code. As I understand it, the redirhell test redirects back to itself, not across servers - my reply was more in sympathy with your server than with the unrelenting client. I'm grateful for your implement of torture, it's been very useful! Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201027/8e66 1808/attachment.htm>
It was thus said that the Great Kevin Sangeelee once stated: > It was consequently queried by the Kind and Honourable Sean Conner: > > > How? Given that a redirection loop can exist across servers. > > The link '/test/redirhell/' generates some unique hex for each new redirect > path, which could alternatively have the hex preserved across redirects, > but with a counter that's incremented instead. If the counter exceeds, say > 11428, then return a '50 YOU ARE DRIVING ME NUTS' response code. > > As I understand it, the redirhell test redirects back to itself, not across > servers - my reply was more in sympathy with your server than with the > unrelenting client. It wasn't "driving me nuts" as in "oh my God! My server is melting under the load!" but more of a "oh, it looks like someone wrote an automated client and didn't limit redirections." Yes, I'll see clients being tested and get caught in the Redirection Hell test, but those tend to make perhaps a few dozen requests before stopping. It was clear to me that the author of the particular client didn't test for infinite redirections, and the only way I can bring the issue up is on the mailing list. > I'm grateful for your implement of torture, it's been very useful! You're welcome. If you can think of any other tests that might be helpful, please don't hesitate to let me know. -spc
On Tue Oct 27, 2020 at 3:16 AM CET, Sean Conner wrote: > Ah, I see that the limit is now mentioned in the Best Practices > document, > not the specification. I could certainly be wrong, but my recollection is that this limit was
---