Hi David, I'm a bit confused as to what are we trying to achieve here, redirect <component>/latest to <component>/<actual latest>, e.g.:
/camel/components/latest to /camel/components/3.12.x Am I on point thus far? Some questions below: On Sun, Oct 31, 2021 at 4:26 PM David Jencks <david.a.jen...@gmail.com> wrote: > > I looked into this a little bit, using the Antora 3 `latest-version-segment` > feature: > > urls: > redirect_facility: httpd > latest_version_segment_strategy: redirect:from > latest_version_segment: latest > > This generates the following in the generated .htaccess: > > Redirect 302 /manual/latest /manual > Redirect 302 /components/latest /components/3.12.x > Redirect 302 /camel-k/latest /camel-k/1.6.x > Redirect 302 /camel-kamelets/latest /camel-kamelets/next > Redirect 302 /camel-quarkus/latest /camel-quarkus/2.4.x > Redirect 302 /camel-kafka-connector/latest /camel-kafka-connector/0.11.0 > Redirect 302 /camel-spring-boot/latest /camel-spring-boot/3.12.x > Redirect 302 /camel-karaf/latest /camel-karaf/3.12.x > - I think in any case we should use Redirect rather than Rewrite as in fact > we want to generate redirects. Both generate a HTTP redirect, and by that I mean 3xx status and a `Location` header, what am I missing here? Btw I would also use `Redirect`, it seems easier to follow and maintain. > - I think we should use 302 rather than 301 since these redirects will change > as we release newer versions. +1 and I think we should do this for both `.../next` and `.../latest` URLs > - I think that a RedirectMatch rule that redirects <project>/<not concrete > version or `next`>/ to the same target is likely to work: such a rule can > easily be generated from the above. Do we need to? Couldn't we use the above generated .htaccess file directly? > So I’m thinking: > > - extract the above from the generated .htaccess > - transform to the <project> >>> <project>/<latest concrete release> form, > and add to generated .htaccess > - insert the generated .htaccess in an appropriate place in static .htaccess Would Antora generate the .htaccess file in the root of the website (i.e. in `documentation` and then copied over to `public`) when built, so it would overwrite the existing .htaccess file from static? If not, i.e. it would generate a .htaccess file per Antora component, we could just leave those there. > I don’t have any good ideas yet on how or where to do this. I imagine the > gulp file would be a good place but I’m not an expert on having gulp > transform individual files. So, if I'm understanding this right, the problem is that the two (or more?) .htaccess files would be generated in the same location and end up overwriting each other. In that case we would need some way of merging them and that we can do using Gulp. Another idea could be to add a Hugo template with similar logic as we do on the download page and generate the desired .htaccess file. The downloads page is fed via the release note's front matter and _if_ we make sure that the documentation is ready for a release, which hasn't been the case for 100% of the releases thus far, that's an approach that can be made to work. zoran -- Zoran Regvart
