Confirmed users
142
edits
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
Clients request files explicitly from the proxxy rather than relying on transparent network proxies, or HTTP_CACHE environment settings. Since the proxxy instances can be handling multiple endpoints, we prepend the hostname of the original url to the proxxy url. e.g. to fetch http://ftp.mozilla.org/foo/bar, the client would first check http://ftp.mozilla.org.proxxy.srv.releng.use1.mozilla.com. Much of this logic is handled by mozharness' proxxy mixin. | Clients request files explicitly from the proxxy rather than relying on transparent network proxies, or HTTP_CACHE environment settings. Since the proxxy instances can be handling multiple endpoints, we prepend the hostname of the original url to the proxxy url. e.g. to fetch http://ftp.mozilla.org/foo/bar, the client would first check http://ftp.mozilla.org.proxxy.srv.releng.use1.mozilla.com. Much of this logic is handled by mozharness' proxxy mixin. | ||
The reasons we chose to have such a setup, rather than a traditional proxy setup, include: | |||
* (main reason): explicit is better than implicit - from the url we can see which cache we are hitting | |||
* transparent proxies are hard to debug or see what's going on | |||
* using http_proxy or env vars may not be obvious in logging | |||
* with traditional proxies it can be difficult to switch to use different backends, or offer multiple proxy instances | |||
If any authentication required, e.g. for pvtbuilds, then proxxy has those credentials baked into the AMI. Test clients on the local network can then request those files from proxxy without authentication. | If any authentication required, e.g. for pvtbuilds, then proxxy has those credentials baked into the AMI. Test clients on the local network can then request those files from proxxy without authentication. | ||