Add router extension to redirect inbound requests from old URL

[mojavelinux]

Add a router extension to select pages that handles inbound requests coming from the old URL and redirects the user to the matching section, if applicable, or page.

We'll assume that the old URL (https://eclipse.dev/jetty) will have a redirect rules such as this one:

location /jetty/documentation/jetty-12/operations-guide/ { return 301 https://jetty.org/docs/jetty/12/operations-guide/; }

The request for the Getting Started section, which has the id og-begin, will arrive at the new site with the root-relative URL:

/docs/jetty/12/operations-guide/#og-begin

That page should have a URL router installed that maps og-begin to a target page and redirects the user to that page. For example:

window.location.href = 'begin/index.html'

This redirect has to be done using JavaScript since only the browser (and hence JavaScript) can see the fragment.

[mojavelinux]

I've submitted a PR with an initial implementation. We'll need to settle on what exactly the rewrite rules will be for the old site before we can finalize the behavior.

[mojavelinux]

@jmcc0nn3ll Could you describe here what redirect facility you plan to put in place on the old site? I can then advice on what rules we need to have to get this hooked up.

[jmcc0nn3ll]

Pretty sure we decided that we were just going to do a hard 301 redirect for everything. I know the last time we were talking about this we were testing that in the browser and I think it all worked. Am I misremembering?

[mojavelinux]

It's not possible to redirect to a single page and preserve the visitor's location. The reason is, you won't know what version the fragment correlates too. So the redirects have to be per version. Though the redirects could be consolidated to a single rule using regexp.

The new site could almost handle redirecting all requests for single version to the start page for that version since the fragments are globally unique within a version (the operations guide and programming guide don't share any IDs). However, if there's no fragment, it won't know if the request is for the operations guide or programming guide. That's why I think the redirect needs to target the guide itself.

To simplify the rewrite configuration, I think the following single rule would work:

rewrite ^/jetty/documentation/(jetty)-(1[012])/(operations-guide|programming-guide)/(?:|index\.html)$ https://jetty.org/docs/$1/$2/$3/ permanent;

(I haven't tested this rule, but I think it's pretty close).

With that in place, we can install the fragment router on the operations and programming guide per version and we should be able to cover almost all (if not all) the requests. A separate rule could be used for the non-documentation pages since those pages are mostly 1-to-1 with the old site.

[jmcc0nn3ll]

My issue is that Eclipse webmasters have piles and piles of redirects from over the years. Multiple times in the last couple of years we have had the jetty website disappear because someone screwed up the rules and we got redirected to the archived JET project.

Am I missing something or couldn't we have a single 301 redirect on eclipse.dev/jetty direct to jetty.org where we use the jetty rewrite handler to rewrite this URL before it gets to the antora site?

[mojavelinux]

What I can tell you is that we provided the router the handle the page splits. You are free to configure the redirections/rewrites from the old site however you'd like, as long as the request for one of the guides in the old site lands on the start page for the guide in the new site. For example, https://eclipse.dev/jetty/documentation/jetty-12/operations-guide/index.html#og-begin lands at https://jetty.org/docs/jetty/12/operations-guide/index.html#og-begin The router we provided will take it from there so that the visitor ends up at https://jetty.org/docs/jetty/12/operations-guide/begin/index.html