Facebook，Google和其他大型应用程序如何做他们的CSS和JavaScript文件？ [英] How do Facebook, Google and other large applications do their CSS and JavaScript files?

问题描述

Facebook： http://static.ak.fbcdn.net/rsrc .php / v1 / yh / r / u2OL99TwlfU.css


Google： http://ssl.gstatic.com/gb/js/sem_cf9545d69b4bd3d22ed10206010c8b23.js

Facebook: http://static.ak.fbcdn.net/rsrc.php/v1/yh/r/u2OL99TwlfU.css
Google: http://ssl.gstatic.com/gb/js/sem_cf9545d69b4bd3d22ed10206010c8b23.js

还有其他网站，如Tagged，也使用这种方法。

There are other sites, like Tagged which also uses this kind of method.

这些网站和其他大型应用程序如何做这些文件？我假设当他们更新他们的文件，URL实际上改变，使缓存不能识别的URL，并重新加载新的文件。

How do these sites and other large applications do these files? I assume when they update their file, the URL actually changes so that the cache doesn't recognise the URL and reloads the new file.

我实际上更困惑Facebook的rsrc.php，但我还是不太明白其余的。看来Google的随机字符串是一个MD5的东西。

I'm actually more confused about Facebook's rsrc.php, but I still don't quite understand the rest. It appears Google's random string is an MD5 of something.

我想在我的网站上这样的东西，大型应用程序使用它，所以它必须是有用的 - 即使

I do want something like this on my websites, large applications use it so it must be useful to use - even if I didn't decide to use, the knowledge of it may be beneficial in the near future.

推荐答案

（我是原来的作者rsrc.php和Facebook的Haste静态资源管理系统。）

(I am the original author of rsrc.php and Facebook's Haste static resource management system.)

您可以找到Facebook遇到的一些与静态资源管理以及如何解决他们的挑战的描述这里，在Phabricator文档中：

You can find a description of some of the challenges Facebook encountered with static resource management and how it solved them here, in the Phabricator documentation:

http： //phabricator.com/docs/phabricator/article/Things_You_Should_Do_Soon:_Static_Resources.html

对于特定问题，rsrc.php URI类似于与rsrc.php在他们）特别是因为我在2007年没有一个全局的Apache重写规则，当我写rsrc.php和添加，部署和测试一个更优雅的URI似乎不值得麻烦PHP，可以在运行时读取x.php文件部分之后的URI的其余部分）。所以这部分只是一个PHP实现工件。

To the specific question, the rsrc.php URIs are like that (with "rsrc.php" in them) specifically because we didn't have a global Apache rewrite rule in 2007 when I wrote rsrc.php and adding, deploying and testing one for some more elegant URI didn't seem worth bothering with (in PHP, you can read the remainder of the URI after the "x.php" file part at runtime). So that part is just a PHP implementation artifact.

其他路径组件已经用于多年的各种事情，如一个紧急版本号，我们可以在全球范围内突破每个人的高速缓存，如果高速缓存流水线出现问题，哈希校验和，所以我们可以区分用于日志记录的有效和垃圾请求，改变用于开发的返回资源的高速缓存策略的内部标志，以及资源的风格（例如，特定浏览器或本地化为特定语言）。

The other path components have been used for various things over the years, like an emergency version number we can bump globally to break everyone's caches if something goes wrong with the cache pipeline, a hash checksum so we can distinguish between valid and garbage requests for logging, internal flags which alter the cache policy of the returned resource for development, and flavors of a resource (e.g., tailored to a specific browser or localized to a specific language).

这篇关于Facebook，Google和其他大型应用程序如何做他们的CSS和JavaScript文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！