The "Proxy Cache" type of project supports access through subdomains without the projectName path.

[xzxiaoshan]

Is your feature request related to a problem? Please describe it.

1. The address of a Docker image consists of FQDN + namespace + imageName:tagName, which we commonly understand as being composed of domain + path.

2. Since projects in Harbor represent the concept of namespaces, when using Harbor to proxy third-party images, a better solution would be to only change the FQDN, rather than adding an extra projectName. Having to include a projectName has caused practical problems for me, and many others have encountered the same issue in community forums and issues.

3. Real-world scenario: When I was deploying Kubernetes with Rancher, I encountered a problem. Rancher's private registry only allows entry of valid FQDNs and does not allow configuration of paths with a projectName suffix, such as allowing only harbor.test.com, but not harbor.test.com/dockerhub-proxy. Since the namespace + imageName:tagName for Kubernetes to build and pull base images is fixed, when I can only configure harbor.test.com, I cannot proceed. I had to manually create a project in Harbor with the same name as the namespace and then manually push dozens of required images before I could use it. This completely defeats the purpose of automatic proxying and is very troublesome.

Describe the solution you want

Desired solution: For all types of proxy projects, automatically assign a subdomain based on the main FQDN, with the subdomain automatically using the projectName. For example, if the main FQDN is harbor.test.com and the project name for proxying Docker Hub is dockerhub-proxy, then the proxy project can be accessed using dockerhub-proxy.harbor.test.com. Accessing dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 is equivalent to accessing harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0.

Advantages: After proxying a third-party repository, besides the change in FQDN, the path part does not need to include the projectName, and the path remains unchanged, which is more suitable for practical application needs and easier to understand.

Describe the main design/architecture of the solution

1. HTTPS certificate issue: Harbor's default certificate uses the wildcard domain *.test.com, which can automatically cover second and third-level domains like dockerhub-proxy.harbor.test.com.

2. Creating a project: The UI adds an automatic assignment of subdomains display.

This subdomain is automatically generated by the project name + main FQDN, with a question mark added afterward to indicate that when accessing the project via the subdomain, the path part can omit the projectName.

3. Code modification: When receiving necessary HTTP requests such as /v2 and /service, read the hostName and main FQDN for comparison, determine if it is a subdomain of the main FQDN, and obtain the projectName.

You can add the projectName to the URL routing through rewrite, or directly handle the request response at the code level with the projectName.

I am a Java engineer and do not understand the programming language of Harbor, so I cannot contribute a PR, sorry.

4. Only image proxy type projects need this; ordinary projects do not need an independent subdomain. Because an independent subdomain fits the logic of proxying third-party images, and ordinary projects consist of projectName + imageName, which conforms to common image path specifications.

Expected final effect

Accessing dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 via docker pull should be consistent with accessing harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0. Equivalent to accessing docker.io/xzxiaoshan/frpc:v0.59.0 .

The difference between dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 and docker.io/xzxiaoshan/frpc:v0.59.0 lies solely in the FQDN.

Thank you, I hope to achieve it.

---

以下问中文，我不确定上面英文翻译表达的是否准确。

---

您的功能请求是否与问题有关？请描述一下
对问题的清晰简洁的描述。例如，当[…]

1、docker镜像的地址由FQDN+namespace+imageName:tagName 组成，我们通俗的把它理解为 domain+path组成。

2、因为 harbor 中项目为单位来指代namespace的概念，当我们使用 harbor 来代理第三方镜像时，更好的方案是只变更 FQDN，而不应该多出一个 projectName，必须带有 projectName 它给我带来了实际问题，再社区圈子里和 issue 里也有很多人遇到一样的问题。

3、实际场景：我在使用 rancher 部署 Kubernetes 时，就遇到了问题。rancher 的私服只能输入合法规范的 FQDN，不允许配置带有 projectName 后缀的路径，例如它只允许写 harbor.test.com，而不允许写 harbor.test.com/dockerhub-proxy。因为 Kubernetes 构建拉取的基础镜像的 namespace+imageName:tagName 是固定的，所以当我只能配置 harbor.test.com 时，我无法进行下去。我手工在harbor中创建了一个 namespace同名的项目，然后手工将所需要的几十个镜像push进去后才可以使用，这样完全失去了自动代理的意义，非常麻烦。

描述您想要的解决方案

期望的解决方案：所有代理类型的项目，自动分配基于主 FQDN 的子域名，子域名自动使用 projectName。例如主 FQDN 是 harbor.test.com，代理 dockerhub 的项目名称为 dockerhub-proxy，那么该代理类型的项目支持使用 dockerhub-proxy.harbor.test.com 来访问。访问 dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 相当于访问 harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0

优点：代理第三方仓库后，除了FQDN发生了变更，path 部分不需要可以增加 projectName，path 没有发生任何改变，更加适合实际应用需求，也更容易理解。

描述解决方案的主要设计/架构

1、https证书问题：harbor 默认证书使用 *.test.com 通配符域名。能自动覆盖二级、三级域名 dockerhub-proxy.harbor.test.com。

2、创建项目：UI 新增自动分配子域名显示。

该子域名为自动规则，由项目名称 + 主 FQDN 组成，后面增加一个问号提示解释通过子域名访问该项目时，path部分可以省略projectName。

3、代码修改：接收到 /v2 和 /service 等必要 http 请求时，读取 hostName 和主 FQDN 进行对比，判断是否为主 FQDN 的子域名，并获取 projectName。

可以通过 rewrite 的方式增加 projectName 进行 url 路由，或者直接在代码底层通过 projectName 直接处理请求的响应。

我是Java工程师，不了解 harbor 的编程语言，无法贡献 PR，很抱歉。

4、只有镜像代理类型的项目才需要，普通项不需要有独立子域名的需求。因为独立子域名符合代理第三方镜像的逻辑，并且普通项目由 projectName+imageName 组成，符合镜像路径常用规范。

期望最终效果

通过 docker pull 访问 dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 和 访问 harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0 是一致的。等同于访问 docker.io/xzxiaoshan/frpc:v0.59.0 。

dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 和 docker.io/xzxiaoshan/frpc:v0.59.0 的区别，只有 FQDN。

谢谢，期望能实现。