制作代理友好站点的指南和最佳实践 [英] Guidelines and best practices to make a proxy-friendly site

问题描述

这是代理和插件开发人员的一个问题。

This is a question to proxy and plugin developers.

当谈到特定网站时，通常的心态是他们做出的改变打破了我们的插件;我们改变逻辑以使其再次起作用。

The usual mindset when it comes to specific sites is "They make changes which breaks our plugin; we change the logic to make it work again".

但是，如果对方也担心这个怎么办？如果我们想为一个代理友好的网站编译一套指南和最佳实践进行网站开发，你建议应该去做什么？想想你必须破解的坚果。你还记得那些你希望网站开发者以不同方式完成某项功能的时刻吗？如何？

But, what if the other side worries about this too? If we want to compile a set of guidelines and best practices for site development for a proxy-friendly site, what do you suggest should go to it? Think of the tough nuts you've had to crack. Do you remember those moments you wished the site developer had done a certain feature differently? How?

由于这与编码有关，我认为它不应该用于服务器故障。

Since this is concerned with coding, I don't think it should go to serverfault.

编辑：
阅读Pekka的评论后，我觉得我应该添加一些更多的背景信息。

After reading Pekka's comment I feel I should add some more background information.

有一些网络代理脚本，例如glype和PHProxy。由于脚本应该处理许多未知条件，因此无法为许多站点提供服务。因为这些网站的数量是压倒性的，所以尝试使代理的内部逻辑足够复杂以处理这种巨大的变化是没有意义的。这是插件派上用场的地方。 main或 base 脚本实现了一种机制，可以在每个站点的基础上调用插件代码。

There are web proxy scripts out there such as glype and PHProxy. As the script should cope with many unknown conditions it fails to serve many sites. Because the number of such sites is overwhelming it does not make sense to try to make the proxy's internal logic sophisticated enough to handle this huge variety. This is where plugins come in handy. The main or base script implements a mechanism to invoke plugin code on a per site bases.

因此，如果代理服务器无法服务，那就让我们说吧facebook.com，顺便提一下，对挑战感兴趣的编码人员会进行一些研究和调试，找出链条被破坏的地点和原因以及应该采取什么措施来解决问题。编码器将他的修复程序实现为该特定站点的插件，用户可以将插件放入他们的插件目录。

So, if the proxy fails to serve let's say facebook.com, which is the case by the way, a coder interested in the challenge does some research and debugging, to find where and why the chain is broken and what should be done to resolve the issue. The coder implements his fix as a plugin for that particular site and users could drop the plugin into their plugins directory.

但是也会发生网站上的某些内容发生变化，该更改导致插件再次中断。因此，赶上网站的最新变化是一个持续的匹配。具有讽刺意味的是，许多网站开发人员既不知道也不关心他们的设计决策可能对内容的代理服务能力产生的影响。但有些网站有充分理由关注访问者通过代理访问其内容的能力。不想在这里进入政界，所以我留给你猜猜为什么这对某些网站来说可能很重要。

But it also happens that something on the site changes, and that change causes the plugin to break again. So it is a constant match to catch up with the most recent changes of a site. The irony of the situation is that many site developers neither know, nor care about the impact their design decisions may have on proxy serve-ability of the content. But some sites have good reason to care about the ability of visitors to access their content through proxies. Don't want to get into politics here, so I leave it to you to guess why this might be important to some sites.

这个问题试图进入代理和插件作者的集体知识和经验，以制定一套使网站代理友好的指南。

This question is an attempt to tap into the collective knowledge and experience of proxy and plugin authors to make a set of guidelines for making a site proxy-friendly.

我没有标记问题php最初因为它主要涉及网站的输出，而不是如何生成它。但决定对其进行标记，因为它会提高问题的可见性，标签也可以在目标受众的基础上进行验证。我也在制作这个社区维基，所以如果你觉得应该删除php标签，就这样做。

推荐答案

<我不确定你是否关心这个问题，但目前我只记得在代理友好网站上工作时应该注意的两件事。一个是标题，可以影响在代理后面访问的网站，另一个是IP检测。缓存控制头（公共/私有）和其他头可以影响用户的速度和隐私。检测到IP可以代理而不是用户。所以，应该记住这些事情。

I am not sure if this of concern to you or not, but currently I only remember two things that should be taken care of when working on a proxy friendly site. One is header that can affect sites visited behind proxy and another is IP detection. Cache-control header (public/private), and other header can affect speed and privacy of the user. IP detected can of of proxy and not of user. So, these things should be kept in mind.

这篇关于制作代理友好站点的指南和最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！