When namespace_in_path is enabled, user/group pages gives 401

Summary

When namespace_in_path is enabled, user/group pages gives 401.

Build version: v16.8.0

Quoting from : #434372 (comment 1747035164)

With a configuration of

external_url 'https://example.org/gitlab'
pages_external_url 'https://pages.example.org'
pages_nginx['enable'] = true

and having set gitlab_pages['namespace_in_path"] = false, i.e. using the DNS wildcard approach as on GitLab SaaS, you can publish user/group, i.e. namespace, pages on https://$namespace.pages.example.org as long as the project path is $namespace/$namespace.pages.example.org.
This is per documentation on the default domain names.

For the non-wildcard case, gitlab_pages['namespace_in_path"] = true, I am trying to publish namespace pages on https://pages.example.org/$namespace but without any success. I have tried a few project paths, and while all publish somewhere, it is not where I want them. So far, I have tried

• $namespace/$namespace.pages.example.org (ends up at https://pages.example.org/$namespace/$namespace.pages.example.org)
• $namespace/pages.example.org (ends up at https://pages.example.org/$namespace/pages.example.org)

Assuming this use case is supported, what project path should I use?

If not supported, can support be added so it follows the current naming convention, i.e. deploying namespace pages from $namespace/$namespace.pages.example.org. This would make switching between the wildcard and non-wildcard scenarios trivial, I think.

Steps to reproduce

Example Project

What is the current bug behavior?

When namespace_in_path is enabled, user/group pages are not accessible.

Example of user/group page: https://pages.example.org/$namespace

What is the expected correct behavior?

User/group page should be accessible via: https://pages.example.org/$namespace

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of: \\\\\\\\\\\\\\\`sudo gitlab-rake gitlab:env:info\\\\\\\\\\\\\\\`) (For installations from source run and paste the output of: \\\\\\\\\\\\\\\`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\\\\\\\\\\\\\\\`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: \\\\\\\`sudo gitlab-rake gitlab:check SANITIZE=true\\\\\\\`) (For installations from source run and paste the output of: \\\\\\\`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true\\\\\\\`) (we will only investigate if the tests are passing)

Possible fixes

No workaround. It should be fixed in Pages lookup path api.