In short: My preferred option would be:
Code: Select all
Access to ajax.googleapis.com
Allow from mysite.com
In long...
I agree that the original "Site" is extremely prone to being misinterpreted.
I think "Request" is good, but I think "Request to" would be even better, as it provides an explicit "to" and "from" which really reinforces the direction:
Code: Select all
Request to ajax.googleapis.com
Allow from mysite.com
To elaborate: there's been a lot of talk about which terms best
imply sending or receiving; but resorting to implication seems crazy when we can simply add the word "to" and make it
explicit (as well as fitting perfectly with the "from" in the lines which follow).
"Access" also seems good. I can't quite decide if it's better than "Request" (the latter has the advantage of being an obvious keyword for people with technical knowledge, and slightly more specific in terms of what it really means). However I would again suggest that "Access to" is a considerable improvement upon just "Access", and in this form I think it's my preferred option:
Code: Select all
Access to ajax.googleapis.com
Allow from mysite.com
"Resource" was briefly debated, and I must agree with Thrawn who pointed out that this term is precisely what is used in the documentation!
A rule looks like this:
Site <resource>
A <resource> is typically an URI pattern (literal, glob or regexp) designing a request destination (site), or a wildcard token such as ALL or SELF.
If it's appropriate for the documentation, I can't understand why it wouldn't be considered for the rule syntax. (If it's not appropriate for the rules, the documentation should be changed.)
As such, "Resource" seems reasonable to me. It's probably not as good as "Request to" or "Access to"; however, if it were not possible to have the " to" suffix, I think "Resource" is perhaps on a par with "Request" and "Access" as a single-word option?
Code: Select all
Resource ajax.googleapis.com
Allow from mysite.com
I think that some of the other suggested aliases remain confusing and prone to misinterpretation by users who do not
already understand that it is a request model.
In that context, I think "On" and "At" are
exactly as ambiguous as "Site".
"Target" would be very nearly as ambiguous as "Site". People can just as easily think "This rule is targetting mysite.com" for the former, as they can think "This rule is for site mysite.com" for the latter.
I think "Destination" is simply confusing if you don't understand that you're referring to a Request. It's not an intuitive replacement at all. "Source" was also suggested. I think the fact that both "Source" and "Destination" have been proposed as labels
for the same thing is indicative of just how confusing this can be, and why maximum clarity should be the goal. I therefore think neither "Source" nor "Destination" are good options.