Closed gloomy-ghost closed 8 years ago
I've already participated in this discussion in pull request #6899 , so @fuglede @Hainish @J0WI please add your comments here.
EDIT: to clarify, my preference in #6899 is for option (2), using special rules rather than many targets or an exclusion with a negative lookahead.
I don't think that the styleguide needs to change here - the wording is open-ended enough to allow reasonable exceptions. Words like "avoid" and "prefer" provide the flexibility needed to allow for option 2. Which is my preference as well.
Since the question has been answered I'm closing this issue.
Sorry, didn't notice the email.
But there are some large rulesets which are using option 3 and it is really looong to write every subdomains in the rule, such as QQ.xml. So are these acceptable or not?
It's case-by-case. In #6899 that you linked above, there are only seven subdomains that need to be listed in one regex, and two subdomains (including one wildcard with \d{1,2}
) in the other. Here is an example of one regex with over twenty subdomains. So I think that if some new rule has a lot more than twenty subdomains in one regex, we can worry about it then. And even then listing each subdomain might be better than whatever the alternative is.
There are 50 subdomains in #6986. I will just leave it there and whoever wants to do that please feel free.
The style guide doesn't like wildcard, it requires a list of subdomains with a plain rewrite rule in rulesets rather than
regexes with long strings of subdomains
.However, some sites have a bunch of subdomains to balance loading pressure, or just to avoid concurrent connections limit in bowsers. Then it is too much to list them all.
A recent example is #6899, in that case we have
c[2-79].yunpan.360.cn
, which have exactly the same function. There are 3 options:regexes with long strings of subdomains
instead of a plain rewrite rule.The style guide notes option 2 and 3 as a bad example, even though option 1 is not an elegant solution. If this still need to consider, another example is McAfee.xml:
Only some certain pages under
www.mcafee.com
have https, and all of the others redirect to http. In this case we don't have option 1, so it seems to be a problem that has no solution if we don't violate the style guide.