希望世间永无欺骗
/thirdparty/phpMyAdmin/
File not found.
yum install kloxomr-thirdparty-phpmyadmin
安装 Kloxo-MR 7.0.0.b 后发现在面板中点击
Url地址 – /thirdparty/phpMyAdmin/
File not found.
打开后找不到文件：
之后在服务组件中也看不到有phpMyAdmin 的信息。
sftp上服务器上的 Kloxo下也确实没有. 也许thirdparty就是要自己装把, 那么就装吧.
如下:
yum list kloxomr-thirdparty*
| 列出以 kloxomr-thirdparty 打头 记得后面有个星号.
kloxomr-thirdparty-phpmyadmin kloxomr-thirdparty-jcterm kloxomr-thirdparty-sshterm-applet
,找到全部的kloxomr第三方插件, 然后安装 phpMyAdmin
yum install kloxomr-thirdparty-phpmyadmin
如此,已经OK!
了解一些帮助您轻松通过 Google 找到信息的提示和技巧。
无论要搜索什么，都请先用简单的字词进行搜索，例如最近的机场在哪里？您随时可以根据需要添加一些描述性字词。
如果您要查找特定地点的某个场所或商品，可添加该地点名称。例如，南京面包店。
不想打字？点击 Google 应用或 Chrome 搜索框中的麦克风图标 ，通过语音执行搜索。
在确定输入搜索框中的字词时，尽量选择要查找的网站上可能会出现的字词。例如，不要使用我的头很痛，而要使用头痛，因为医学网站上往往会使用后者。
QQ 与 qq 所得到的结果是一样的。对于您进行的许多搜索，Google 都会替您完成相关工作，并会在您输入搜索字词后在搜索结果页上显示相关解答。有些功能（例如查询与球队有关的信息）并非在所有地区都提供。
天气可查看您所在地点的天气信息，如果在“天气”后加上城市名（例如天气北京），则可查看相应城市的天气信息。define 即可查询其定义。3*9123）或求解复杂的图形公式。3 美元兑换欧元。您可以使用特殊的字符和字词来获取更具体的搜索结果。Google 会忽略大部分的标点符号（以下示例除外）。例如，搜索字词狗！ 会被 Google 视为狗。
即使以下符号均受支持，在您的搜索中加入这些符号也并不一定会改善搜索结果。如果我们认为该标点不会为您提供更好的结果，则会显示出不含标点的搜索字词所对应的建议结果。
请注意：在使用符号进行搜索时，请勿在符号和搜索字词之间添加空格。我们可以识别-狗中的符号，但无法识别- 狗中的符号。
| 符号 | 用途 |
|---|---|
+ |
搜索 Google+ 网页或血型 示例：+Chrome 和 AB+ |
@ |
查找社交标记 示例：@agoogler |
$ |
查找价格 示例： 尼康 $400 |
# |
查找热门主题标签以搜索热门话题 示例：#throwbackthursday |
- |
移除字词在某个字词或网站之前添加一个短横可排除所有包含该字词或网站的搜索结果。在搜索有多种含义的字词（例如“汽车品牌捷豹”和“动物捷豹”）时，这种方法尤为实用。
示例： 连字如果多个字词以短横相连，Google 便会知道这些字词是紧密关联的。 示例： |
_ |
用于连接两个字词，例如 quick_sort。 您会在搜索结果中发现，这对字词要么组成一个字词 (quicksort)，要么由下划线相连 (quick_sort)。 |
" |
如果您将字词或词组置于引号中，则搜索结果中将仅显示以下网页：包含引号中的字词且字词顺序也与引号中相同。 请注意：请仅在需要搜索某个精确字词或词组时使用这种搜索方式，不然，可能会错误地排除掉很多有用的搜索结果。 示例："想象一下所有人" |
* |
在搜索中添加一个星号，以表示任何未知或不确定的字词。与引号结合使用，可以查找具体词组的不同变体，或记住词组中间的字词。 示例："省*就是赚*" |
.. |
使用不含空格的两个半角句号 (..) 隔开多个数字，即可查看日期、价格和尺寸等方面的数值在指定范围内的搜索结果。 示例：相机 $50..$100 |
搜索运算符是可添加到搜索字词中以帮助缩小搜索结果范围的字词。不必担心，您不一定要记住每个运算符，因为您也可以使用“高级搜索”页面来进行这种搜索。
请注意：使用运算符进行搜索时，请勿在运算符和搜索字词之间添加空格。搜索 site:nytimes.com 可以获取相关搜索结果，而搜索 site: nytimes.com 则是行不通的。
| 运算符 | 用途 |
|---|---|
site: |
仅从特定网站或网域获得搜索结果。例如，您可以查找 NBC 网站或任何 .gov 网站上所有提到“奥运”的内容。 示例：olympics site:nbc.com 和 olympics site:.gov |
link: |
查找链接到某个特定网页的页面。例如，您可以查找链接到 google.com.hk 的所有页面。 示例：link:google.com.hk |
related: |
查找与您已浏览过的网址类似的网站。当您搜索与 time.com 相关的网站时，会找到您可能感兴趣的其他新闻出版物网站。 示例：related:time.com |
OR |
如果您想搜索可能只包含多个搜索字词中某一个的页面，可以在这些字词之间加上 OR（大写）。如果不加 OR，您的搜索结果中通常只会显示与这些字词都匹配的页面。 示例：世界杯举办地2014年OR 2018年 |
info: |
获取某网址的相关信息，包括网页的缓存版本、相似网页和链接至该网站的网页。 示例：info:google.com |
cache: |
查看 Google 上次抓取网站时网页的外观。 示例：cache:washington.edu |
VPS的内存对性能至关重要，所以很有必要优化一下。
看了几篇针对vps小内存优化的文章，于是自己也动手参照优化下自己的mysql。
修改过调整好的 my.cnf ，service mysqld restart 启动时报错。
查看log，发现 skip-innodb / skip-bdb / skip-locking，这几个参数有问题。
继续学习，查资料，得知 使用的参数都是老版本的参数，mysql5.1对应的为：
skip-innodb –> loose-skip-innodb
skip-locking –> skip-external-locking
skip-bdb (已经废除了skip-bdb这个参数！)
配置文件: /etc/my.cnf
# low memory stuff – Mr.Tang
# Tue May 26 22:23:15 CST 2015[mysqld]
loose-skip-innodb
skip-external-locking
skip-host-cache
skip-name-resolvecharacter_set_server = utf8
default-storage-engine = myisamkey_buffer_size = 256M
key_buffer = 256K
max_allowed_packet = 1M
myisam_sort_buffer_size = 8M
net_buffer_length = 128K
query_cache_size= 16M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
sort_buffer_size = 1M
table_cache = 4M
table_open_cache = 16M
thread_cache_size = 8M
thread_stack = 131072[mysqldump]
quick
max_allowed_packet = 16M[mysql]
no-auto-rehash
#safe-updates[isamchk]
key_buffer = 8M
sort_buffer_size = 8M[myisamchk]
key_buffer_size = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M[mysqlhotcopy]
interactive-timeout
近几个月发现空间经常很慢，特别是WordPress响应非常迟钝，但一直懒得动它。 前几天实在受不了，正巧看到一个特价的vps，就用paypal支付了$，买了一个． 搞好了系统，配置好环境，就在准备迁移WordPress数据的时候，偶然看到一个文章，说近来几个月很多人的WordPress都是变的很慢。 查了查相关文章，跟google被墙有关，原因是wp的字体加载的都是 在google托管的，还有些js，css脚本等等，比如：
<link href='http://fonts.googleapis.com/css?family=Open+Sans:300,400,600&subset=latin,latin-ext' rel='stylesheet'> <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"> <script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js?ver=3.4.2'></script>
这样 googleapis.com，googlecode.com 无法联通，自然相关引用的字体，脚本也都无法加载，只有等待主机超时， 所以WordPress都变的很慢。 知道问题所在就处理它。
1。不使用google字体
编辑主题的 functions.php文件，在末尾添加以下代码：
//禁用Open Sans
class Disable_Google_Fonts {
public function __construct() {
add_filter( ‘gettext_with_context’, array( $this, ‘disable_open_sans’ ), 888, 4 );
}
public function disable_open_sans( $translations, $text, $context, $domain ) {
if ( ‘Open Sans font: on or off’ == $context && ‘on’ == $text ) {
$translations = ‘off’;
}
return $translations;
}
}
$disable_google_fonts = new Disable_Google_Fonts;
2。手动修改替换引用地址
打开wordpress文件： wp-includes/script-loader.php
搜： fonts.googleapis.com
替换：fonts.googleapis.com替换为 fonts.useso.com ，保存文件，发现问题解决了。
原理就是用360来加速google字体。
速度很好，360的加速很快。
3。使用插件
如何通过第三方Wordpress字体转换插件继续使用Google字体库？ (感谢来自淘宝的soulteary童鞋开发了这个插件) 插件说明地址：http://www.soulteary.com/2014/06/08/replace-google-fonts.html 插件下载地址：http://www.soulteary.com/wp-content/uploads/2014/06/Replace-Google-Fonts.zip
—- P.S. 这样暂时就不用站点迁移了. 差点误会了服务商.
winform中使用webBrowser抽取页面中的一些数据。断点“webBrowser1_DocumentCompleted”发现，跑进来了好多次。
DocumentCompleted执行多次，跟踪发现ReadyState状态不一样，分别是Intercative和Complete。
而MSDN对这两种状态值的解释是：
增加判断“ReadyState”之后继续，DocumentCompleted仍然执行了两次，但ReadyState状态一样都是Complete。再查原因。
MSDN对其解释是在多个的帧的情况下DocumentComplete获取触发多次。并非每个框架将触发此事件，但触发DownloadBegin事件的每个框架将触发相应的DocumentComplete事件。
最后webBrowser1_DocumentCompleted中的代码是：
private void webBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
string BrowserUrl = webBrowser1.Url.ToString();
if (String.IsNullOrEmpty(BrowserUrl)) //检查未赋值或空值
return;
if (BrowserUrl.Equals("about:blank")) //是否为空白页
return;
if (webBrowser1.ReadyState != WebBrowserReadyState.Complete) //状态为完成
return;
if (e.Url.ToString() != BrowserUrl) //检查事件url和webBrowser的url
return;
if (webBrowser1.DocumentText == "")
return;
... ...
}
还有一点，就是窗体打开就加载webBrowser1，如放在 Form_Load 会使程序界面加载很慢，建议放在 Form_Shown中（每当窗体第一次显示时发生）。
在DirectAdmin下更新WordPress版本,主题或插件时, 经常出现: “下载失败。 文件流的目标目录不存在或不可写。”的错误提示.
或者是模板，插件”无法删除xxx。”等问题。
这跟文件权限的设置有关，处理方法如下：.
先进入DirectAdmin后台，选择域名站点，在进入”File Manager”.
然后进入“wp-content”文件夹下，勾选”plugins“，”themes“，”upgrade“，”uploads“等有问题的文件夹。
在下面的”set Permission“后设置权限”777“或者”755“， 勾选后面的”Recursive“遍历选项，再点击”set Permission“按钮。
然后可以尝试下更新或删除是否正常。
如果还不行， 可能是文件权限的所有者改变了，可以点击”Reset Owner“，
重置文件所有者再试一次。
一般问题都可以解决了。
—————————————————
再者就是主机服务商的一键脚本安装wordpress时引发的 在DirectAdmin或者cPanel虚拟主机通常带的快速安装wp脚本，如果不进行特殊设置会在wp-config.php文件里面加入 “WP_TEMP_DIR” 属性,此属性虽然有助于确定wordpress下载升级包或者插件时所用的路径但是也有缺点。 也就是说如果你在更换空间时忘记修改了此属性的绝对路径就会出现以上的错误
解决办法是：空间更换完毕后自行修改wp-config里的此项属性所对应的缓存目录的绝对路径，目标文件夹权限设为777。 或者删除类似这样的代码define('WP_TEMP_DIR', '/home/xxx.com/wp-content/uploads');
另一种：
通过wordpress后台，无法删除插件。甚至通过FTP也无法删除。也就是说删除之后，仍然显示在后台插件列表内。
这主要是因为插件有隐藏/嵌套的文件，没有出现在FTP.
使用 SSH 访问博客
| 状态码 | 含义 |
|---|---|
| 100 | 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。 |
| 101 | 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 |
| 102 | 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 |
| 200 | 请求已成功，请求所希望的响应头或数据体将随此响应返回。 |
| 201 | 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted’。 |
| 202 | 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。 返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。 |
| 203 | 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。 |
| 204 | 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。 如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。 由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。 |
| 205 | 服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。 与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。 |
| 206 | 服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。 该请求必须包含 Range 头信息来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。 响应必须包含如下的头部域： Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。 Date ETag 和/或 Content-Location，假如同样的请求本应该返回200响应。 Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了 If-Range 强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。 假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。 任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。 |
| 207 | 由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。 |
| 300 | 被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。 除非这是一个 HEAD 请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。 如果服务器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。 |
| 301 | 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。 新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个301响应的话，接下来的重定向请求将会变成 GET 方式。 |
| 302 | 请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。 |
| 303 | 对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。 新的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。 注意：许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。 |
| 304 | 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。 该响应必须包含以下的头信息： Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。 ETag 和/或 Content-Location，假如同样的请求本应返回200响应。 Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。 假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使用了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。 假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。 假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。 |
| 305 | 被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。 注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。 |
| 306 | 在最新版的规范中，306状态码已经不再被使用。 |
| 307 | 请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。 新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求，否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。 如果这不是一个GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。 |
| 400 | 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。 |
| 401 | 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。 |
| 402 | 该状态码是为了将来可能的需求而预留的。 |
| 403 | 服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。 |
| 404 | 请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。 |
| 405 | 请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。 |
| 406 | 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 除非这是一个 HEAD 请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。 |
| 407 | 与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。 |
| 408 | 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。 |
| 409 | 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。 冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。 |
| 410 | 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。 410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为’410 Gone’，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。 |
| 411 | 服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。 |
| 412 | 服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。 |
| 413 | 服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。 如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。 |
| 414 | 请求的URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括： 本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。 重定向URI “黑洞”，例如每次重定向把旧的 URI 作为新的 URI 的一部分，导致在若干次重定向后 URI 超长。 客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI，当 GET 后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。 |
| 415 | 对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。 |
| 416 | 如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。 假如 Range 使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个 Content-Range 实体头，用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。 |
| 417 | 在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。 |
| 421 | 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 |
| 422 | 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。 |
| 422 | 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）423 Locked 当前资源被锁定。（RFC 4918 WebDAV） |
| 424 | 由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV） |
| 425 | 在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。 |
| 426 | 客户端应当切换到TLS/1.0。（RFC 2817） |
| 449 | 由微软扩展，代表请求应当在执行完适当的操作后进行重试。 |
| 500 | 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。 |
| 501 | 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。 |
| 502 | 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。 |
| 503 | 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。 注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。 |
| 504 | 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。 注意：某些代理服务器在DNS查询超时时会返回400或者500错误 |
| 505 | 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。 |
| 506 | 由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。 |
| 507 | 服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918) |
| 509 | 服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。 |
| 510 | 获取资源所需要的策略并没有没满足。（RFC 2774） |
QQ登录失败一例 – 系统维护中
【QQ 版本】Build 15.67.330
【QQ 号码】47404844
【操作系统】Microsoft Windows 2000 Service Pack 4 [Build 5.0.2195]
【网络设置】局域网内使用透明代理
【登录过程】
—————————————————————————
开始登录……时间[2006-08-24 04:38:28]
初始化登录服务器列表，上次的登录方式为【UDP登录方式】
尝试UDP方式登录,先创建UDP网络组件
创建UDP网络组件成功，本地IP【61.52.***.***】,端口【4000】，直接登录上一次登录过的服务器，
确定登录UDP服务器IP【219.133.49.172】,端口【8000】
向登录服务器发送新登录第一步骤数据
收到服务器登录第一步骤的回应，回应成功，发送第二步骤的数据
发送登录第一步骤的数据成功，发送第二步骤的数据
收到登录服务器登录第二步骤的回应，登录失败，原因：登录失败,提示信息: 系统维护中,请稍后再登录
在一家又一家注定要倒闭的dot-com公司工作过之后，一位名叫Bram Cohen的年轻程序员最终厌倦了这种失败的生活。
“最终我认为我想做一些人们会实际用到的、有用的并且有趣的项目。”他回忆到。
3年后，28岁的Cohen成为了下一波互联网文件共享风潮的掌门人。如果说Napster是文件交换的第一浪，像Kazaa这样的文件交换网络则代表了第二浪。那么，由Cohen开发的BitTorrent将会引领文件交换的第三浪——目前BitTorrent实际的用户难以估量，但是BitTorrent这个软件至少被下载了超过1000万次。
在早期形式的文件交换网络被唱片业穷追猛打以致步向衰落的同时，像BitTorrent这样的新技术的出现，使得用于视频的大文件的共享和分发 变得更加容易。例如，光是suprnova.org这样的一个网站，就能提供上百套电视节目、最新电影以及版权软件。这甚至令到一向在打击互联网文件交换 中不太积极的电影工业也开始提高警惕。
然而，Cohen对他所创造的这个系统早已经失去了控制。他表示，当他开发这个系统的时候，大规模的侵犯版权问题是他没有想到的。相反，他开发 这个系统的初衷，是为了使人们在购买合法在线音乐时，不需要再经历那漫长的等待。“很明显，他们的问题在于没有足够的带宽来满足人们的需要。”Cohen 在接受采访时称，“我很清楚，实际上有很多的带宽摆在那里，但是它没有被恰当的使用。还有许多上传容量是人们没用到的。”
这就是BitTorrent背后的本质。在像Napster和Kazaa这样旧有的文件共享系统下，实际上只有一小部分人把文件向世人分享，大 部分用户都只是简单地下载。然而BitTorrent则使用了所谓的Golden Rule原理：你上传的速度越快，你下载的速度就越快。BitTorrent把文件分割成许多小块，当一个用户下载了某一小块时，它就会立即把这一小块上 传给其它用户。因此，所有的用户在下载的同时，也在把自己已下载部分上传给他人。BitTorrent的这种工作原理，使得做“种子”的用户只需少许带 宽，就可以把大文件共享给大量的下载者。
BitTorrent对于Cohen来说，一直是一种脑力训练而不是一种赚钱的途径。不像其它文件交换程序，BitTorrent不但是免费的，而且还是开源的。这意味着只要有足够能力，你完全可以把BitTorrent融入到你自己的程序里面。
BitTorrent的第一个可用版本出现在2002年10月，不过这个版本还有许多要改进的地方。然而，Cohen此时却在为生计发愁。幸运 的是，BitTorrent引起了著名免费软件企业家John Gilmore的注意。Gilmore帮助Cohen解决了部分的生活费用，使得BitTorrent免遭夭折。
BitTorrent真正流行起来是在2003年初，它被用来发布一个新版的Linux。与此同时，还有一些日本卡通的fans凭籍它来共享动画片。
很难衡量BitTorrent的总体使用情况。但是Internet2主干网基础构造的主管Steven C. Corbato表示，他在去年5月份开始就注意到，BitTorrent的流量开始激增。从10月份开始，BitTorrent的流量更是超过了这个超高 速网络总体流量的10%。与之对比，其它的文件交换系统的流量没有一个能超过Internet2总体流量的1%。Internet2又称Abilene主 干，它连接起了美国200多所规模最大的大学，速度比现时的ADSL要快3500多倍。
尽管BitTorrent获得了如此巨大的成功，然而直到几个月前，它并没有为Cohen带来过一分钱。“去年9月份我没有一丁点钱，”Cohen回忆到，他当时只好利用这张信用卡的免息期来透支，填补另一张信用卡的帐单来过活。
Cohen那时并不知道，BitTorrent会为他带来一份工作。某天，他的事情为Valve软件公司的常务董事Gabe Newell所获悉。尽管Valve正在开发令游戏玩家望眼欲穿的Half-Life 2，但是它同时也在建立一个名为Steam的在线分发网络。由于Cohen掌握这个领域的专门技术，所以Valve为他提供了一个职位。Cohen从十月 份起搬到西雅图，开始了他的工作。
一直以来，Cohen都有通过他的网站bitconjurer.org来接受BitTorrent用户的捐款，但是这笔金额一直很少。然而从10月份开始，Cohen父亲鼓励他请求的更直接一点。如今，Cohen称，他每天都能收到上百美元的捐款。
“在过去的几个月，我的生活方式发生了相当戏剧性的变化，获得工作还有捐款的到来，”Cohen说，“这好极了。”
根据Pew Internet和American Life Project的调查数据显示，文件交换正在衰落，这显然是唱片业起诉运动的结果。在去年5月，29%美国的成年互联网用户表示他们参与了文件交换。而到 了11月和12月份，这个数字已经跌到了14%。但是，BitTorrent的忠实用户——无论是卡通狂热爱好者、Linux用户、盗版电影的观赏者—— 似乎在不断增加。
BitTorrent的用户中有不少人对Cohen心怀感激，但是毫不奇怪，电影工业的圈内人不在此列。“BitTorrent决对是处在我们 的雷达防线以内。”美国电影协会的主管Tom Temple在一次电话访问中表示。BitTorrent的迅猛普及，促使该协会开始向BitTorrent站点的管理人发出了侵权通知。
“我们正在调查大量的BitTorrent链接网站，在不久的将来我们可能会向某些站点提出民事或刑事起诉。”Temple称。
对此，Cohen指出，BitTorrent的用户是非匿名的，他们的互联网IP地址很容易就能被看到。“这令我很吃惊，像Suprnova这样的网站竟然能够继续生存，因为他们很容易就会被起诉。”Cohen称。Cohen还补充说，使用BitTorrent来进行非法交易，是“很愚蠢的，因为它不是匿名的。而且由于基层结构的关系，它也不能被改成匿名的。
这就是说，Cohen并不支持许多BitTorrent站点的做法。
“我不打算拿出傲慢的态度，告诉其它人不该怎么做，因为斥责他人的事情与我无关。”他说，“我是以那种找乐子的心态来看待这件事的。”