2011-01-25 18:59:31 +01:00
|
|
|
<?php
|
|
|
|
|
2012-10-17 17:37:05 +02:00
|
|
|
abstract class CelerityResourceController extends PhabricatorController {
|
2011-01-31 20:55:26 +01:00
|
|
|
|
2012-10-17 17:37:05 +02:00
|
|
|
protected function buildResourceTransformer() {
|
|
|
|
return null;
|
|
|
|
}
|
2011-01-31 20:55:26 +01:00
|
|
|
|
Make CelerityController extend PhabricatorController
Summary:
Currently, CelerityController extends AphrontController, not PhabricatorController. (I think I imagined Celerity being somewhat stand-alone and didn't want to create a dependency.)
This creates a concrete problem if a static resource is missing, since we throw an exception, but the higher-level exception handlers depend on the User existing in order to show an appropriate response page. This is the only controller which doesn't extend PhabricatorController, and it doesn't seem worthwhile to make a weird edge case out of it.
Specific repro case is:
- Remove `externals/javelin/` (or forget to run `git submodule update --init`).
- Load a static resource.
- Get "[Rendering Exception] Argument 1 passed to PhabricatorMainMenuView::setUser() must be an instance of PhabricatorUser, null given, called in /services/apache/phabricator/phabricator/src/view/page/PhabricatorStandardPageView.php on line 435 and defined"
Test Plan:
- Followed above steps, no more fataling.
- Verified this is the only weird controller.
Reviewers: voldern, vrana, btrahan
Reviewed By: voldern
CC: aran
Differential Revision: https://secure.phabricator.com/D3389
2012-08-28 22:46:35 +02:00
|
|
|
public function shouldRequireLogin() {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function shouldRequireEnabledUser() {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-05-01 19:23:02 +02:00
|
|
|
public function shouldAllowPartialSessions() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-02-13 00:22:56 +01:00
|
|
|
public function shouldAllowLegallyNonCompliantUsers() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-01-01 16:46:18 +01:00
|
|
|
abstract public function getCelerityResourceMap();
|
2014-01-01 04:21:56 +01:00
|
|
|
|
Don't cache resources we can't generate properly
Summary:
Fixes T10843. In a multi-server setup, we can do this:
- Two servers, A and B.
- You push an update.
- A gets pushed first.
- After A has been pushed, but before B has been pushed, a user loads a page from A.
- It generates resource URIs like `/stuff/new/package.css`.
- Those requests hit B.
- B doesn't have the new resources yet.
- It responds with old resources.
- Your CDN caches things. You now have a poisoned CDN: old data is saved in a new URL.
To try to avoid this with as little work as possible and generally make it hard to get wrong, check the URL hash against the hash we would generate.
If they don't match, serve our best guess at the resource, but don't cache it. This should make things mostly keep working during the push, but prevent caches from becoming poisoned, and everyone should get a working version of everything after the push finishes.
Test Plan:
- `curl`'d a resource, got a cacheable one.
- Changed the hash a little, `curl`'d again. This time: valid resource, but not cacheable.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10843
Differential Revision: https://secure.phabricator.com/D15775
2016-04-21 00:14:35 +02:00
|
|
|
protected function serveResource(array $spec) {
|
|
|
|
$path = $spec['path'];
|
|
|
|
$hash = idx($spec, 'hash');
|
|
|
|
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
// Sanity checking to keep this from exposing anything sensitive, since it
|
|
|
|
// ultimately boils down to disk reads.
|
|
|
|
if (preg_match('@(//|\.\.)@', $path)) {
|
|
|
|
return new Aphront400Response();
|
|
|
|
}
|
|
|
|
|
|
|
|
$type = CelerityResourceTransformer::getResourceType($path);
|
Serve .eot and .ttf through Celerity
Summary:
D9153 fixed half of this, but exposed another issue, which is that we don't actually serve ".eot" and ".ttf" through Celerity right now.
Make sure we include them in the routes.
Test Plan:
- Downloaded CSS, JS, TTF, EOT, WOFF, JPG, etc., through Celerity.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9154
2014-05-16 18:53:18 +02:00
|
|
|
$type_map = self::getSupportedResourceTypes();
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
|
|
|
|
if (empty($type_map[$type])) {
|
2015-05-22 09:27:56 +02:00
|
|
|
throw new Exception(pht('Only static resources may be served.'));
|
2011-01-25 18:59:31 +01:00
|
|
|
}
|
2011-01-31 20:55:26 +01:00
|
|
|
|
2014-05-22 19:47:00 +02:00
|
|
|
$dev_mode = PhabricatorEnv::getEnvConfig('phabricator.developer-mode');
|
|
|
|
|
Don't cache resources we can't generate properly
Summary:
Fixes T10843. In a multi-server setup, we can do this:
- Two servers, A and B.
- You push an update.
- A gets pushed first.
- After A has been pushed, but before B has been pushed, a user loads a page from A.
- It generates resource URIs like `/stuff/new/package.css`.
- Those requests hit B.
- B doesn't have the new resources yet.
- It responds with old resources.
- Your CDN caches things. You now have a poisoned CDN: old data is saved in a new URL.
To try to avoid this with as little work as possible and generally make it hard to get wrong, check the URL hash against the hash we would generate.
If they don't match, serve our best guess at the resource, but don't cache it. This should make things mostly keep working during the push, but prevent caches from becoming poisoned, and everyone should get a working version of everything after the push finishes.
Test Plan:
- `curl`'d a resource, got a cacheable one.
- Changed the hash a little, `curl`'d again. This time: valid resource, but not cacheable.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10843
Differential Revision: https://secure.phabricator.com/D15775
2016-04-21 00:14:35 +02:00
|
|
|
$map = $this->getCelerityResourceMap();
|
|
|
|
$expect_hash = $map->getHashForName($path);
|
|
|
|
|
|
|
|
// Test if the URI hash is correct for our current resource map. If it
|
|
|
|
// is not, refuse to cache this resource. This avoids poisoning caches
|
|
|
|
// and CDNs if we're getting a request for a new resource to an old node
|
|
|
|
// shortly after a push.
|
2016-04-27 15:42:32 +02:00
|
|
|
$is_cacheable = ($hash === $expect_hash);
|
|
|
|
$is_locally_cacheable = $this->isLocallyCacheableResourceType($type);
|
Don't cache resources we can't generate properly
Summary:
Fixes T10843. In a multi-server setup, we can do this:
- Two servers, A and B.
- You push an update.
- A gets pushed first.
- After A has been pushed, but before B has been pushed, a user loads a page from A.
- It generates resource URIs like `/stuff/new/package.css`.
- Those requests hit B.
- B doesn't have the new resources yet.
- It responds with old resources.
- Your CDN caches things. You now have a poisoned CDN: old data is saved in a new URL.
To try to avoid this with as little work as possible and generally make it hard to get wrong, check the URL hash against the hash we would generate.
If they don't match, serve our best guess at the resource, but don't cache it. This should make things mostly keep working during the push, but prevent caches from becoming poisoned, and everyone should get a working version of everything after the push finishes.
Test Plan:
- `curl`'d a resource, got a cacheable one.
- Changed the hash a little, `curl`'d again. This time: valid resource, but not cacheable.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10843
Differential Revision: https://secure.phabricator.com/D15775
2016-04-21 00:14:35 +02:00
|
|
|
if (AphrontRequest::getHTTPHeader('If-Modified-Since') && $is_cacheable) {
|
2011-05-09 10:10:40 +02:00
|
|
|
// Return a "304 Not Modified". We don't care about the value of this
|
|
|
|
// field since we never change what resource is served by a given URI.
|
|
|
|
return $this->makeResponseCacheable(new Aphront304Response());
|
|
|
|
}
|
|
|
|
|
2014-05-22 19:47:00 +02:00
|
|
|
$cache = null;
|
|
|
|
$data = null;
|
2016-04-27 15:42:32 +02:00
|
|
|
if ($is_cacheable && $is_locally_cacheable && !$dev_mode) {
|
2014-05-22 19:47:00 +02:00
|
|
|
$cache = PhabricatorCaches::getImmutableCache();
|
|
|
|
|
|
|
|
$request_path = $this->getRequest()->getPath();
|
|
|
|
$cache_key = $this->getCacheKey($request_path);
|
|
|
|
|
|
|
|
$data = $cache->getKey($cache_key);
|
|
|
|
}
|
2011-01-31 20:55:26 +01:00
|
|
|
|
2014-05-22 19:47:00 +02:00
|
|
|
if ($data === null) {
|
|
|
|
if ($map->isPackageResource($path)) {
|
|
|
|
$resource_names = $map->getResourceNamesForPackageName($path);
|
|
|
|
if (!$resource_names) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
|
|
|
try {
|
|
|
|
$data = array();
|
|
|
|
foreach ($resource_names as $resource_name) {
|
|
|
|
$data[] = $map->getResourceDataForName($resource_name);
|
|
|
|
}
|
|
|
|
$data = implode("\n\n", $data);
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
try {
|
|
|
|
$data = $map->getResourceDataForName($path);
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
return new Aphront404Response();
|
2011-01-30 01:10:05 +01:00
|
|
|
}
|
|
|
|
}
|
2014-05-22 19:47:00 +02:00
|
|
|
|
|
|
|
$xformer = $this->buildResourceTransformer();
|
|
|
|
if ($xformer) {
|
|
|
|
$data = $xformer->transformResource($path, $data);
|
2011-01-30 01:10:05 +01:00
|
|
|
}
|
2011-01-25 18:59:31 +01:00
|
|
|
|
2014-05-22 19:47:00 +02:00
|
|
|
if ($cache) {
|
|
|
|
$cache->setKey($cache_key, $data);
|
|
|
|
}
|
2012-10-17 17:37:05 +02:00
|
|
|
}
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
|
2011-01-25 18:59:31 +01:00
|
|
|
$response = new AphrontFileResponse();
|
|
|
|
$response->setContent($data);
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
$response->setMimeType($type_map[$type]);
|
2014-03-06 20:28:24 +01:00
|
|
|
|
|
|
|
// NOTE: This is a piece of magic required to make WOFF fonts work in
|
2015-05-04 01:16:50 +02:00
|
|
|
// Firefox and IE. Possibly we should generalize this more.
|
|
|
|
|
|
|
|
$cross_origin_types = array(
|
|
|
|
'woff' => true,
|
|
|
|
'woff2' => true,
|
|
|
|
'eot' => true,
|
|
|
|
);
|
|
|
|
|
|
|
|
if (isset($cross_origin_types[$type])) {
|
2014-03-06 20:28:24 +01:00
|
|
|
// We could be more tailored here, but it's not currently trivial to
|
|
|
|
// generate a comprehensive list of valid origins (an install may have
|
|
|
|
// arbitrarily many Phame blogs, for example), and we lose nothing by
|
|
|
|
// allowing access from anywhere.
|
2014-06-09 20:36:49 +02:00
|
|
|
$response->addAllowOrigin('*');
|
2014-03-06 20:28:24 +01:00
|
|
|
}
|
|
|
|
|
Don't cache resources we can't generate properly
Summary:
Fixes T10843. In a multi-server setup, we can do this:
- Two servers, A and B.
- You push an update.
- A gets pushed first.
- After A has been pushed, but before B has been pushed, a user loads a page from A.
- It generates resource URIs like `/stuff/new/package.css`.
- Those requests hit B.
- B doesn't have the new resources yet.
- It responds with old resources.
- Your CDN caches things. You now have a poisoned CDN: old data is saved in a new URL.
To try to avoid this with as little work as possible and generally make it hard to get wrong, check the URL hash against the hash we would generate.
If they don't match, serve our best guess at the resource, but don't cache it. This should make things mostly keep working during the push, but prevent caches from becoming poisoned, and everyone should get a working version of everything after the push finishes.
Test Plan:
- `curl`'d a resource, got a cacheable one.
- Changed the hash a little, `curl`'d again. This time: valid resource, but not cacheable.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10843
Differential Revision: https://secure.phabricator.com/D15775
2016-04-21 00:14:35 +02:00
|
|
|
if ($is_cacheable) {
|
|
|
|
$response = $this->makeResponseCacheable($response);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $response;
|
2011-05-09 10:10:40 +02:00
|
|
|
}
|
|
|
|
|
Serve .eot and .ttf through Celerity
Summary:
D9153 fixed half of this, but exposed another issue, which is that we don't actually serve ".eot" and ".ttf" through Celerity right now.
Make sure we include them in the routes.
Test Plan:
- Downloaded CSS, JS, TTF, EOT, WOFF, JPG, etc., through Celerity.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D9154
2014-05-16 18:53:18 +02:00
|
|
|
public static function getSupportedResourceTypes() {
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
return array(
|
|
|
|
'css' => 'text/css; charset=utf-8',
|
|
|
|
'js' => 'text/javascript; charset=utf-8',
|
|
|
|
'png' => 'image/png',
|
2015-11-22 22:03:58 +01:00
|
|
|
'svg' => 'image/svg+xml',
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
'gif' => 'image/gif',
|
2014-04-03 18:18:42 +02:00
|
|
|
'jpg' => 'image/jpeg',
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
'swf' => 'application/x-shockwave-flash',
|
2014-03-06 20:28:24 +01:00
|
|
|
'woff' => 'font/woff',
|
2015-02-09 17:12:47 +01:00
|
|
|
'woff2' => 'font/woff2',
|
2014-04-18 02:31:23 +02:00
|
|
|
'eot' => 'font/eot',
|
|
|
|
'ttf' => 'font/ttf',
|
2015-03-10 22:20:00 +01:00
|
|
|
'mp3' => 'audio/mpeg',
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2011-05-09 10:10:40 +02:00
|
|
|
private function makeResponseCacheable(AphrontResponse $response) {
|
2011-01-27 20:35:04 +01:00
|
|
|
$response->setCacheDurationInSeconds(60 * 60 * 24 * 30);
|
2011-05-09 10:10:40 +02:00
|
|
|
$response->setLastModified(time());
|
Don't require one-time tokens to view file resources
Summary:
Ref T10262. This removes one-time tokens and makes file data responses always-cacheable (for 30 days).
The URI will stop working once any attached object changes its view policy, or the file view policy itself changes.
Files with `canCDN` (totally public data like profile images, CSS, JS, etc) use "cache-control: public" so they can be CDN'd.
Files without `canCDN` use "cache-control: private" so they won't be cached by the CDN. They could still be cached by a misbehaving local cache, but if you don't want your users seeing one anothers' secret files you should configure your local network properly.
Our "Cache-Control" headers were also from 1999 or something, update them to be more modern/sane. I can't find any evidence that any browser has done the wrong thing with this simpler ruleset in the last ~10 years.
Test Plan:
- Configured alternate file domain.
- Viewed site: stuff worked.
- Accessed a file on primary domain, got redirected to alternate domain.
- Verified proper cache headers for `canCDN` (public) and non-`canCDN` (private) files.
- Uploaded a file to a task, edited task policy, verified it scrambled the old URI.
- Reloaded task, new URI generated transparently.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10262
Differential Revision: https://secure.phabricator.com/D15642
2016-04-06 22:06:34 +02:00
|
|
|
$response->setCanCDN(true);
|
2011-01-25 18:59:31 +01:00
|
|
|
|
|
|
|
return $response;
|
|
|
|
}
|
|
|
|
|
2014-05-22 19:47:00 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is it appropriate to cache the data for this resource type in the fast
|
|
|
|
* immutable cache?
|
|
|
|
*
|
|
|
|
* Generally, text resources (which are small, and expensive to process)
|
|
|
|
* are cached, while other types of resources (which are large, and cheap
|
|
|
|
* to process) are not.
|
|
|
|
*
|
|
|
|
* @param string Resource type.
|
|
|
|
* @return bool True to enable caching.
|
|
|
|
*/
|
2016-04-27 15:42:32 +02:00
|
|
|
private function isLocallyCacheableResourceType($type) {
|
2014-05-22 19:47:00 +02:00
|
|
|
$types = array(
|
|
|
|
'js' => true,
|
|
|
|
'css' => true,
|
|
|
|
);
|
|
|
|
|
|
|
|
return isset($types[$type]);
|
|
|
|
}
|
|
|
|
|
2015-06-20 15:10:42 +02:00
|
|
|
protected function getCacheKey($path) {
|
2015-06-01 18:04:22 +02:00
|
|
|
return 'celerity:'.PhabricatorHash::digestToLength($path, 64);
|
2014-05-22 19:47:00 +02:00
|
|
|
}
|
|
|
|
|
2011-01-25 18:59:31 +01:00
|
|
|
}
|