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
|
|
|
|
2016-12-13 23:02:04 +01:00
|
|
|
$response = id(new AphrontFileResponse())
|
2017-04-18 22:17:39 +02:00
|
|
|
->setMimeType($type_map[$type]);
|
|
|
|
|
Emit a "Content-Security-Policy" HTTP header
Summary:
See PHI399. Ref T4340. This header provides an additional layer of protection against various attacks, including XSS attacks which embed inline `<script ...>` or `onhover="..."` content into the document.
**style-src**: The "unsafe-inline" directive affects both `style="..."` and `<style>`. We use a lot of `style="..."`, some very legitimately, so we can't realistically get away from this any time soon. We only use one `<style>` (for monospaced font preferences) but can't disable `<style>` without disabling `style="..."`.
**img-src**: We use "data:" URIs to inline small images into CSS, and there's a significant performance benefit from doing this. There doesn't seem to be a way to allow "data" URIs in CSS without allowing them in the document itself.
**script-src** and **frame-src**: For a small number of flows (Recaptcha, Stripe) we embed external javascript, some of which embeds child elements (or additional resources) into the document. We now whitelist these narrowly on the respective pages.
This won't work with Quicksand, so I've blacklisted it for now.
**connect-src**: We need to include `'self'` for AJAX to work, and any websocket URIs.
**Clickjacking**: We now have three layers of protection:
- X-Frame-Options: works in older browsers.
- `frame-ancestors 'none'`: does the same thing.
- Explicit framebust in JX.Stratcom after initialization: works in ancient IE.
We could probably drop the explicit framebust but it wasn't difficult to retain.
**script tags**: We previously used an inline `<script>` tag to start Javelin. I've moved this to `<data data-javelin-init ...>` tags, which seems to work properly.
**`__DEV__`**: We previously used an inline `<script>` tag to set the `__DEV__` mode flag. I tried using the "initialization" tags for this, but they fire too late. I moved it to `<html data-developer-mode="1">`, which seems OK everywhere.
**CSP Scope**: Only the CSP header on the original request appears to matter -- you can't refine the scope by emitting headers on CSS/JS. To reduce confusion, I disabled the headers on those response types. More headers could be disabled, although we're likely already deep in the land of diminishing returns.
**Initialization**: The initialization sequence has changed slightly. Previously, we waited for the <script> in bottom of the document to evaluate. Now, we go fishing for tags when domcontentready fires.
Test Plan:
- Browsed around in Firefox, Safari and Chrome looking for console warnings. Interacted with various Javascript behaviors. Enabled Quicksand.
- Disabled all the framebusting, launched a clickjacking attack, verified that each layer of protection is individually effective.
- Verified that the XHProf iframe in Darkconsole and the PHPAST frame layout work properly.
- Enabled notifications, verified no complaints about connecting to Aphlict.
- Hit `__DEV__` mode warnings based on the new data attribute.
- Tried to do sketchy stuff with `data:` URIs and SVGs. This works but doesn't seem to be able to do anything dangerous.
- Went through the Stripe and Recaptcha workflows.
- Dumped and examined the CSP headers with `curl`, etc.
- Added a raw <script> tag to a page (as though I'd found an XSS attack), verified it was no longer executed.
Maniphest Tasks: T4340
Differential Revision: https://secure.phabricator.com/D19143
2018-02-27 15:56:15 +01:00
|
|
|
// The "Content-Security-Policy" header has no effect on the actual
|
|
|
|
// resources, only on the main request. Disable it on the resource
|
|
|
|
// responses to limit confusion.
|
|
|
|
$response->setDisableContentSecurityPolicy(true);
|
|
|
|
|
2017-04-18 22:17:39 +02:00
|
|
|
$range = AphrontRequest::getHTTPHeader('Range');
|
|
|
|
|
|
|
|
if (strlen($range)) {
|
|
|
|
$response->setContentLength(strlen($data));
|
|
|
|
|
|
|
|
list($range_begin, $range_end) = $response->parseHTTPRange($range);
|
|
|
|
|
|
|
|
if ($range_begin !== null) {
|
|
|
|
if ($range_end !== null) {
|
|
|
|
$data = substr($data, $range_begin, ($range_end - $range_begin));
|
|
|
|
} else {
|
|
|
|
$data = substr($data, $range_begin);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$response->setContentIterator(array($data));
|
|
|
|
} else {
|
|
|
|
$response
|
|
|
|
->setContent($data)
|
|
|
|
->setCompressResponse(true);
|
|
|
|
}
|
|
|
|
|
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',
|
Support ".ico" in Celerity and simplify rewite rule configuration
Summary:
See D16734.
- Add ".ico" files to the Celerity map.
- Add a formal route for "/favicon.ico".
- Remove instructions to configure `/rsrc/` and `/favicon.ico` rewrite rules.
Long ago, we served resources directly via `/rsrc/` in at least some cases. As we added more features, this stopped working more and more often (for example, Apache can never serve CSS this way, because it doesn't know how to post-process `{$variables}`).
In modern code (until this change), only `/favicon.ico` is still expected to be served this way.
Instead, serve it with an explicit route via controller (this allows different Sites to have different favicons, for example).
Remove the instructions suggesting the old rewrite rules be configured. It's OK if they're still in place -- they won't break anything, so we don't need to rush to get users to delete them.
We should keep "webroot/favicon.ico" in place for now, since it needs to be there for users with the old rewrite rule.
Test Plan:
- Ran celerity map.
- Loaded `/favicon.ico`, got resource via route.
- Used `celerity_generate_resource_uri()` to get paths to other icons, loaded them, got icons.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D16737
2016-10-20 20:14:33 +02:00
|
|
|
'ico' => 'image/x-icon',
|
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
|
|
|
}
|