You can use the wildcard character ( * ) to make your environment available for several subdomains (for example, *.example.com).
Wildcard characters only match a single subdomain level but do not match multiple subdomain levels separated by a dot. For example, *.example.com can match against a.example.com and a-blog.example.com but cannot match against a.b.example.com or a.b.c.example.com.
To cover subdomains of various levels, a wildcard is required at the relevant subdomain level. You can use a single wildcard in each record. For example, *.example.com, *.b.example.com, *.b.c.example.com are all legitimate and match against a.example.com, a.b.example.com, a.b.c.example.com respectively.
Incoming requests for a domain are first processed by the load balancer, which directs the requests to the proper infrastructure. After the infrastructure receives the request, Apache handles routing the requests to the proper website by matching the requests to the configured site root directory. Unexpected behavior can result when wildcard domains (*.example.com) are used.
Due to the way Apache processes domain matching, traffic might be routed to the environment with the wildcard domain, instead of the explicitly-named domain you intended.
Unlike Nginx on the load balancer, Apache processes domain names alphanumerically, in the order they appear in the configuration files, instead of respecting more specific domains before wildcard domains. This ordering can lead to a wildcard domain configured for one environment catching traffic you intended to route to a different environment.
For example, let’s say we have a customer using the sitenamedelightful on Cloud Platform Professional. Since Cloud Platform Professional appends random alphanumeric strings to sitenames, the resulting configuration files would appear like this:
These configuration files correspond to the following environments on this infrastructure:
Dev = delightful978inmswak-152457.conf
Prod = delightful82upsouk-168414.conf
Test/Staging = delightfulmlhjfbjppg-154567.conf
Inside each of these configuration files are a set of variables called ServerAlias. These variables are the domain names displayed on your Domains page. The configuration files mentioned above contain the following ServerAlias definitions:
If a request is received for test.delightful.com, the request would be caught by the *.delightful.com rule, which Apache reads before the ServerAlias for test.delightful.com. The content for test.delightful.com would appear on the production environment, instead of non-production environment.
It is not possible to circumvent the method Apache handles wildcard behavior in the domain matching process. If you determine that your subscription is serving the wrong version of your website, and you use wildcard domains, try removing the wildcard to attempt to resolve the issue.
Apache and wildcard domains on Cloud Platform
Note
You can use the wildcard character ( * ) to make your environment available for several subdomains (for example, *.example.com).
Wildcard characters only match a single subdomain level but do not match multiple subdomain levels separated by a dot. For example, *.example.com can match against a.example.com and a-blog.example.com but cannot match against a.b.example.com or a.b.c.example.com.
To cover subdomains of various levels, a wildcard is required at the relevant subdomain level. You can use a single wildcard in each record. For example, *.example.com, *.b.example.com, *.b.c.example.com are all legitimate and match against a.example.com, a.b.example.com, a.b.c.example.com respectively.
Incoming requests for a domain are first processed by the load balancer, which directs the requests to the proper infrastructure. After the infrastructure receives the request, Apache handles routing the requests to the proper website by matching the requests to the configured site root directory. Unexpected behavior can result when wildcard domains (*.example.com) are used.
Due to the way Apache processes domain matching, traffic might be routed to the environment with the wildcard domain, instead of the explicitly-named domain you intended.
Unlike Nginx on the load balancer, Apache processes domain names alphanumerically, in the order they appear in the configuration files, instead of respecting more specific domains before wildcard domains. This ordering can lead to a wildcard domain configured for one environment catching traffic you intended to route to a different environment.
For example, let’s say we have a customer using the sitenamedelightful on Cloud Platform Professional. Since Cloud Platform Professional appends random alphanumeric strings to sitenames, the resulting configuration files would appear like this:
These configuration files correspond to the following environments on this infrastructure:
Dev = delightful978inmswak-152457.conf
Prod = delightful82upsouk-168414.conf
Test/Staging = delightfulmlhjfbjppg-154567.conf
Inside each of these configuration files are a set of variables called ServerAlias. These variables are the domain names displayed on your Domains page. The configuration files mentioned above contain the following ServerAlias definitions:
If a request is received for test.delightful.com, the request would be caught by the *.delightful.com rule, which Apache reads before the ServerAlias for test.delightful.com. The content for test.delightful.com would appear on the production environment, instead of non-production environment.
It is not possible to circumvent the method Apache handles wildcard behavior in the domain matching process. If you determine that your subscription is serving the wrong version of your website, and you use wildcard domains, try removing the wildcard to attempt to resolve the issue.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform