From 310fd066e91f454b990372ffa30e803cc8120975 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:56:40 +0100 Subject: unslug zh-cn: move --- files/zh-cn/conflicting/web/http/cors/index.html | 249 +++++++++++++++++++++ files/zh-cn/conflicting/web/http/csp/index.html | 36 +++ .../index.html | 97 ++++++++ .../index.html | 56 +++++ files/zh-cn/conflicting/web/http/status/index.html | 13 ++ 5 files changed, 451 insertions(+) create mode 100644 files/zh-cn/conflicting/web/http/cors/index.html create mode 100644 files/zh-cn/conflicting/web/http/csp/index.html create mode 100644 files/zh-cn/conflicting/web/http/csp_9583294484b49ac391995b392c2b1ae1/index.html create mode 100644 files/zh-cn/conflicting/web/http/csp_aeae68a149c6fbe64e541cbdcd6ed5c5/index.html create mode 100644 files/zh-cn/conflicting/web/http/status/index.html (limited to 'files/zh-cn/conflicting/web/http') diff --git a/files/zh-cn/conflicting/web/http/cors/index.html b/files/zh-cn/conflicting/web/http/cors/index.html new file mode 100644 index 0000000000..50a52b3405 --- /dev/null +++ b/files/zh-cn/conflicting/web/http/cors/index.html @@ -0,0 +1,249 @@ +--- +title: Server-Side Access Control +slug: Web/HTTP/Server-Side_Access_Control +tags: + - AJAX + - CORS + - HTTP + - PHP +translation_of: Web/HTTP/CORS +translation_of_original: Web/HTTP/Server-Side_Access_Control +--- +

{{HTTPSidebar}}

+ +

浏览器会针对从 {{domxref("XMLHttpRequest")}} 或Fetch API中发起的跨网站请求发送特定的HTTP标头。它还希望看到使用跨站点响应发送回的特定HTTP标头。这些标头的概述，包括启动请求和处理来自服务器的响应的示例JavaScript代码, 以及每个头的讨论，可以在HTTP访问控制（CORS）文章中找到，应该作为本文的配套文章阅读。

+ +

HTTP访问控制文章是很好的使用指南。本文介绍利用PHP处理访问控制请求和制定访问控制响应。本文的目标读者是服务器程序员或管理员。虽然在PHP代码示例所示,类似的概念适用于ASP.net,Perl、Python、Java等;一般来说,这些概念可以应用于任何服务器端编程环境处理HTTP请求和动态制定的HTTP响应。

+ +

讨论HTTP标头

+ +

了解HTTP 头部信息, 建议先阅读这篇文章 covering the HTTP headers used by both clients (such as Firefox 3.5 and beyond) and servers

+ +
 
+ +

工作代码示例

+ +

随后的章节中PHP代码（和JavaScript调用服务器）可查看相关代码，这些代码在实现了XMLHttpRequest的浏览器上都可运行，像Firefox 3.5及以上。

+ +
 
+ +

简单的跨站请求

+ +

简单的访问控制请求 在下列情况下会被发起：

+ + + +

以下情况，请求会返回相关响应信息

+ + + +

 简单的访问控制请求 介绍了在客户端和服务端进行信息交换的HEADER.  下面是一段用来处理简单请求的PHP代码。

+ +
<?php
+
+// 我们将只授予 arunranga.com 域的访问权限，因为我们认为它通过 application/xml 方式来访问这些资源是安全的。
+
+if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com")
+{
+
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Content-type: application/xml');
+    readfile('arunerDotNetResource.xml');
+}
+else
+{
+header('Content-Type: text/html');
+echo "<html>";
+echo "<head>";
+echo "   <title>Another Resource</title>";
+echo "</head>";
+echo "<body>",
+    "<p>This resource behaves two-fold:";
+echo "<ul>",
+        "<li>If accessed from <code>http://arunranga.com</code> it returns an XML document</li>";
+echo " <li>If accessed from any other origin including from simply typing in the URL into the browser's address bar,";
+echo "you get this HTML document</li>",
+    "</ul>",
+"</body>",
+"</html>";
+}
+?>
+
+ +

上面的代码通过检查浏览器发送的 ORIGIN 头部信息（通过 $_SERVER['HTTP_ORIGIN'] ) 是否匹配 'http://arunranga.com' 得知，如果是，返回 Access-Control-Allow-Origin: http://arunranga.com 。如果你的浏览器支持访问控制，你可以访问 这里 .

+ +

预请求

+ +

预请求 发生在下列情况中：

+ + + +

预请求访问控制 这篇文章介绍了在客户端和服务器间进行交换的头信息，响应preflight requests请求的服务器资源会有这些动作：

+ + + +

下面是相关的PHP内容， preflighted request:

+ +
<?php
+if($_SERVER['REQUEST_METHOD'] == "GET")
+{
+    header('Content-Type: text/plain');
+    echo "This HTTP resource is designed to handle POSTed XML input from arunranga.com and not be retrieved with GET";
+
+}
+elseif($_SERVER['REQUEST_METHOD'] == "OPTIONS")
+{
+    // 告诉客户端我们支持来自 arunranga.com 的请求并且预请求有效期将仅有20天
+    if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com")
+    {
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
+    header('Access-Control-Allow-Headers: X-PINGARUNER');
+    header('Access-Control-Max-Age: 1728000');
+    header("Content-Length: 0");
+    header("Content-Type: text/plain");
+    //exit(0);
+    }
+    else
+    {
+    header("HTTP/1.1 403 Access Forbidden");
+    header("Content-Type: text/plain");
+    echo "You cannot repeat this request";
+
+    }
+}
+elseif($_SERVER['REQUEST_METHOD'] == "POST")
+{
+    /* 通过首先获得XML传送过来的blob来处理POST请求，然后做一些处理, 最后将结果返回客户端
+    */
+    if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com")
+    {
+            $postData = file_get_contents('php://input');
+            $document = simplexml_load_string($postData);
+
+            // 对POST过来的数据进行一些处理
+
+            $ping = $_SERVER['HTTP_X_PINGARUNER'];
+
+
+            header('Access-Control-Allow-Origin: http://arunranga.com');
+            header('Content-Type: text/plain');
+            echo // 处理之后的一些响应
+    }
+    else
+        die("POSTing Only Allowed from arunranga.com");
+}
+else
+    die("No Other Methods Allowed");
+
+?>
+
+ +

可以看到，就像POST一样，针对OPTIONS preflight请求，同样返回对应的头信息。这样 以来，处理preflight就像处理普通的request请求一样，在针对OPTIONS请求的响应信息中，服务器通过客户端，实际的请求可以用POST的形式发送，同时可附加X-PINGARUNERP这样的头信息。如果浏览器支持的话，可访问 这里

+ +

凭证请求

+ +

带凭据的请求，将Cookies和HTTP认证信息一起发送出去的跨域请求，根据请求方式，可以是 Simple 或 Preflighted,

+ +

发送 简单请求 时, Firefox 3.5 (或以上)会发送带Cookies信息的请求，  (如果withCredentials 设以true). 如果服务器响应真的是可信任的, 客户端接受并进行输出。 在 预请求 中,服务器可以针对 OPTIONS 请求，返回 Access-Control-Allow-Credentials: true 信息

+ +

下面是处理请求的PHP内容:

+ +
<?php
+
+if($_SERVER['REQUEST_METHOD'] == "GET")
+{
+
+    // First See if There Is a Cookie
+    //$pageAccess = $_COOKIE['pageAccess'];
+    if (!isset($_COOKIE["pageAccess"])) {
+
+    setcookie("pageAccess", 1, time()+2592000);
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Cache-Control: no-cache');
+    header('Pragma: no-cache');
+    header('Access-Control-Allow-Credentials: true');
+    header('Content-Type: text/plain');
+    echo 'I do not know you or anyone like you so I am going to mark you with a Cookie :-)';
+
+    }
+    else
+    {
+
+    $accesses = $_COOKIE['pageAccess'];
+    setcookie('pageAccess', ++$accesses, time()+2592000);
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Access-Control-Allow-Credentials: true');
+    header('Cache-Control: no-cache');
+    header('Pragma: no-cache');
+    header('Content-Type: text/plain');
+    echo 'Hello -- I know you or something a lot like you!  You have been to ', $_SERVER['SERVER_NAME'], ' at least ', $accesses-1, ' time(s) before!';
+    }
+
+}
+elseif($_SERVER['REQUEST_METHOD'] == "OPTIONS")
+{
+    // Tell the Client this preflight holds good for only 20 days
+    if($_SERVER['HTTP_ORIGIN'] == "http://arunranga.com")
+    {
+    header('Access-Control-Allow-Origin: http://arunranga.com');
+    header('Access-Control-Allow-Methods: GET, OPTIONS');
+    header('Access-Control-Allow-Credentials: true');
+    header('Access-Control-Max-Age: 1728000');
+    header("Content-Length: 0");
+    header("Content-Type: text/plain");
+    //exit(0);
+    }
+    else
+    {
+    header("HTTP/1.1 403 Access Forbidden");
+    header("Content-Type: text/plain");
+    echo "You cannot repeat this request";
+
+    }
+}
+else
+    die("This HTTP Resource can ONLY be accessed with GET or OPTIONS");
+
+
+
+?>
+
+ +

需要注意的是，在带凭据请求中， Access-Control-Allow-Origin: 头不能是通配符 "*"，必须是一个有效的域名。  可参考这里 running here

+ +

Apache示例

+ +

限制对某些URI的访问

+ +

最有效的方法之一，利用Apache rewrite, 环境变量，还有headers使Access-Control-Allow-* 对某些特定的URI生效，比如，以无认证信息形式利用GET跨域请求api(.*).json。

+ +
RewriteRule ^/api(.*)\.json$ /api$1.json [CORS=True]
+Header set Access-Control-Allow-Origin "*" env=CORS
+Header set Access-Control-Allow-Methods "GET" env=CORS
+Header set Access-Control-Allow-Credentials "false" env=CORS
+
+ +

参见

+ + diff --git a/files/zh-cn/conflicting/web/http/csp/index.html b/files/zh-cn/conflicting/web/http/csp/index.html new file mode 100644 index 0000000000..232b502c3f --- /dev/null +++ b/files/zh-cn/conflicting/web/http/csp/index.html @@ -0,0 +1,36 @@ +--- +title: 内容安全策略 (CSP) +slug: Web/Security/CSP +translation_of: Web/HTTP/CSP +translation_of_original: Web/Security/CSP +--- +
{{gecko_minversion_header("2.0")}}
+ +

内容安全策略 (CSP, Content Security Policy) 是一个附加的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本 (XSS) 和数据注入等攻击。 这些攻击可用于实现从数据窃取到网站破坏或作为恶意软件分发版本等用途。

+ +

尽管内容安全策略在 Firefox 4 中已经包含，使用 X-Content-Security-Policy 头部来实现，但它使用的是过时的 CSP 标准。Firefox 23 包含了更新的 CSP 实现，使用的是 W3C CSP 1.0 标准中描述的没有前缀的 Content-Security-Policy 头部和指令。

+ +

内容安全策略主题

+ +
+
介绍内容安全策略
+
概述什么是 CSP，以及它如何让你的网站变得更安全。
+
CSP 策略指令
+
CSP 策略指令参考。
+
使用内容安全策略
+
你可以通过配置策略集调整 CSP 的行为。这让你可以按需对个别类型的资源使用宽松或严格的安全策略。这篇文章讲述了如何建立 CSP 和如何激活你网站的 CSP。
+
使用 CSP 违规报告
+
如何使用 CSP 违规报告来监视攻击你网站的尝试和攻击者。
+
默认 CSP 限制 {{obsolete_inline("15.0")}}
+
CSP 强制实施的默认限制的细节
+
+ +

另请参阅

+ + diff --git a/files/zh-cn/conflicting/web/http/csp_9583294484b49ac391995b392c2b1ae1/index.html b/files/zh-cn/conflicting/web/http/csp_9583294484b49ac391995b392c2b1ae1/index.html new file mode 100644 index 0000000000..2577fa1fde --- /dev/null +++ b/files/zh-cn/conflicting/web/http/csp_9583294484b49ac391995b392c2b1ae1/index.html @@ -0,0 +1,97 @@ +--- +title: Using CSP violation reports +slug: Web/Security/CSP/Using_CSP_violation_reports +translation_of: Web/HTTP/CSP +translation_of_original: Web/Security/CSP/Using_CSP_violation_reports +--- +

{{ gecko_minversion_header("2.0") }}{{ draft() }}

+ +

CSP其中的一个强大的特性是它为web站点管理员提供了生成和报告详细的站点攻击的描述信息。这些报告通过HTTP的POST请求发送到预先你指定的一个或多个服务器上，这些服务器可以通过 report-uri 策略来制定。发送的报告是JSON格式的，对于非ASCII字符，其使用了默认的JSON UTF-8编码。本文将向你展示如何在你的站点上配置报告，以及报告的格式。

+ +

对于支持CSP的浏览器，只要你制定了合法的 report-uri 指令，任何违背该策略的攻击操作都会被浏览器所报告。

+ +

开启报告

+ +

默认情况下，攻击是不会被报告的。要开启报告模式，你要指定 report-uri 指令，这个指令包含了至少一个用于接收报告的URI:

+ +
Content-Security-Policy: default-src self; report-uri http://reportcollector.example.com/collector.cgi
+
+ +

然后，你要搭建接受报告的服务器；它可以对报告进行存储和并进行适时的处理。

+ +

注意：Firefox 23以前的版本所使用的报告头为 X-Content-Security-Policy。这个头在将来将被废弃。

+ +

攻击报告的语法

+ +

报告的JSON对象包含了以下的数据:

+ +
+
document-uri
+
当前攻击所发生的文档的URI。
+
referrer
+
当前攻击所发生的文档的来源页面的URI。
+
blocked-uri
+
被CSP策略所拦截的资源的URI。如果被拦截资源的URI属于与当前文档不同的来源，则所拦截的资源URI会被削减至只剩scheme,host和port三部分。
+
violated-directive
+
攻击所针对的策略部分的名称
+
original-policy
+
由X-Content-Security-Policy头指定的原始策略。
+
+ +

Sample violation report

+ +

攻击报告的样例

+ +
在CSP规范中，已经有一个样例展示攻击报告。这里我们来看另一个例子。
+ +
 
+ +
假设有一个页面叫做http://example.com/signup.html. 它使用了一下的策略，它禁止从除cdn.example.com以外的域加载样式表。
+ +
+
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+
+
+ +
signup.html的HTML则像下面这样：
+ +
<!DOCTYPE html>
+<html>
+  <head>
+    <title>Sign Up</title>
+    <link rel="stylesheet" href="css/style.css">
+  </head>
+  <body>
+    ... Content ...
+  </body>
+</html>
+
+ +
看到问题了么？在策略中指明样式表只能从cdn.example.com加载，而这个页面则试图从它本域（http://example.com）下载样式表. 浏览器基于强制CSP的开启，在这个页面被访问时，将以下的报告通过POST请求发送到 http://example.com/_/csp-reports 下
+ +
{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}
+
+ +

我们可以看到，这个报告在blocked-uri中包含了错误资源的整个路径。而这并非总是这样。例如，当signup.html试图从http://anothercdn.example.com/stylesheet.css加载css的时候，浏览器只会记录来源(http://anothercdn.example.com)而不会记录完整的路径。CSP规范中对这一行为进行了解释。总结一下，CSP的作用是放置跨域信息的泄露。值得注意的是，规范中的 攻击报告范例 有一处错误(其中blocked-uri应该是"http://evil.example.com")。

+ +

更多参考

+ + + +
+

{{ languages( { "ja": "ja/Security/CSP/Using_CSP_violation_reports" } ) }}

+
+ +

 

diff --git a/files/zh-cn/conflicting/web/http/csp_aeae68a149c6fbe64e541cbdcd6ed5c5/index.html b/files/zh-cn/conflicting/web/http/csp_aeae68a149c6fbe64e541cbdcd6ed5c5/index.html new file mode 100644 index 0000000000..ce27f52be4 --- /dev/null +++ b/files/zh-cn/conflicting/web/http/csp_aeae68a149c6fbe64e541cbdcd6ed5c5/index.html @@ -0,0 +1,56 @@ +--- +title: 内容安全策略介绍 +slug: Web/Security/CSP/Introducing_Content_Security_Policy +tags: + - 介绍 + - 内容安全策略 + - 安全 +translation_of: Web/HTTP/CSP +translation_of_original: Web/Security/CSP/Introducing_Content_Security_Policy +--- +

{{ gecko_minversion_header("2") }}

+ +

内容安全策略 (CSP)  是一个附加的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本 (XSS) 和数据注入等攻击。 这些攻击可用于实现从数据窃取到网站破坏或作为恶意软件分发版本等用途。

+ +

CSP被设计成向后兼容；不支持的浏览器依然可以运行使用了它的服务器页面，反之亦然。不支持CSP的浏览器会忽略它，像平常一样运行，默认对网页内容使用标准的同源策略。如果网站不提供CSP头部，浏览器同样会使用标准的同源策略。

+ +

开启CSP就如配置您的页面服务来返回Content-Security-Policy HTTP 头部一样简单. (Firefox 23之前的版本使用的是X-Content-Security-Policy ). 查看 Using Content Security Policy 获取如何配置和开启CSP的细节

+ +
提示： 内容安全策略标准特点 是一种能被 {{ HTMLElement("meta") }}元素来配置的一种协议，但这种做法仍未被Firefox支持， 支持这种做法是被添加在bug 663570.
+ +

减少跨域脚本

+ +

CSP的主要目标是减少和报告XSS攻击. XSS攻击利用浏览器对从服务器接受的内容的信任。恶意的脚本在受害的浏览器被执行, 因为浏览器相信内容源，甚至当内容源并不是从它应该来的地方过来的。

+ +

CSP使服务器管理员能够通过制定浏览器能够执行的可信赖脚本的域名来减少或者消除由XSS可能出现的矢量。 一个兼容CSP的浏览器将只会执行加载与白名单域名的源文件的脚本，忽略那些其他的脚本（包括内联脚本和事件操控HTML属性）

+ +

作为一种最终的保护，想要禁止脚本的站点可以选择全局禁止脚本执行

+ +

减少数据包监听攻击

+ +

为了重新约束内容被下载的域名, 服务端能够制定那种协议能够被使用；例如（理论上，从安全的立足点来看），一个服务制定所有的内容都通过HTTPS协议来加载

+ +
提示：一个完整地数据传输安全策略不单单包括通HTTPS加强数据的传输，还可以使所有cookie带上安全标志并且提供从HTTP页面到对应HTTPS页面的自动重定向。
+ +
提示：站点可能也会使用 Strict-Transport-Security HTTP头部来确保浏览器只通过一个加密渠道来连接他们
+ +

See also

+ + + +

Specification

+ + + +
+

{{ languages( { "ja": "ja/Introducing_Content_Security_Policy" } ) }}

+
+ +

 

diff --git a/files/zh-cn/conflicting/web/http/status/index.html b/files/zh-cn/conflicting/web/http/status/index.html new file mode 100644 index 0000000000..2c0fce1058 --- /dev/null +++ b/files/zh-cn/conflicting/web/http/status/index.html @@ -0,0 +1,13 @@ +--- +title: HTTP response codes +slug: Web/HTTP/HTTP_response_codes +translation_of: Web/HTTP/Status +translation_of_original: Web/HTTP/HTTP_response_codes +--- +

HTTP状态码(响应码)用来表明这个HTTP 请求是否已经成功完成.HTTP响应类型一共分五大类:消息响应,成功响应,重定向,客户端错误,服务器端错误.

+

 

+

下表列出了所有HTTP状态码,以及他们各自所代表的含义:

+ +
状态码   原因短语 代表含义 HTTP 版本   
消息响应
100          Continue
(继续)		 客户端应当继续发送请求.这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝.客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应.服务器必须在请求完成后向客户端发送一个最终响应. HTTP/1.1 可用
101 Switching Protocol
(切换协议)		 服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到 在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特 性的资源。 HTTP/1.1 可用
成功响应
200 OK
(成功)		 请求成功.成功的意义根据请求所使用的方法不同而不同.
  • GET: 资源已被提取,并作为响应体传回客户端.
  • HEAD: 实体头已作为响应头传回客户端
  • POST: 经过服务器处理客户端传来的数据,适合的资源作为响应体传回客户端.
  • TRACE: 服务器收到请求消息作为响应体传回客户端.
PUT, DELETE, 和 OPTIONS 方法永远不会返回 200 状态码.		 HTTP/0.9 可用
201 Created
(已创建)		 请求成功，而且有一个新的资源已经依据请求的需要而建立，通常这是 PUT 方法得到的响应码. HTTP/0.9 可用
202 Accepted
(已创建)		 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。:返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。 HTTP/0.9 可用
203 Non-Authoritative Information
(未授权信息)

服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝,如果不是上述情况,使用200状态码才是最合适的.

 HTTP/0.9 and 1.1
204 No Content
(无内容)		 该响应没有响应内容,只有响应头,响应头也可能是有用的.用户代理可以根据新的响应头来更新对应资源的缓存信息. HTTP/0.9 可用
205 Reset Content
(重置内容)		 告诉用户代理去重置发送该请求的窗口的文档视图. HTTP/1.1 可用
206 Partial Content
(部分内容)		 当客户端通过使用range头字段进行文件分段下载时使用该状态码 HTTP/1.1 可用
重定向
300 Multiple Choice
(多种选择)		 该请求有多种可能的响应,用户代理或者用户必须选择它们其中的一个.服务器没有任何标准可以遵循去代替用户来进行选择. HTTP/1.0 and later
301 Moved Permanently
(永久移动)		 该状态码表示所请求的URI资源路径已经改变,新的URL会在响应的Location:头字段里找到. HTTP/0.9 可用
302 Found
(临时移动)		 该状态码表示所请求的URI资源路径临时改变,并且还可能继续改变.因此客户端在以后访问时还得继续使用该URI.新的URL会在响应的Location:头字段里找到. HTTP/0.9 可用
303 See Other
(查看其他位置)		 服务器发送该响应用来引导客户端使用GET方法访问另外一个URI. HTTP/0.9 and 1.1
304 Not Modified
(未修改)		 告诉客户端,所请求的内容距离上次访问并没有变化. 客户端可以直接从浏览器缓存里获取该资源. HTTP/0.9 可用
305 Use Proxy
(使用代理)		 所请求的资源必须统过代理才能访问到.由于安全原因,该状态码并未受到广泛支持. HTTP/1.1 可用
306 unused
(未使用)		 这个状态码已经不再被使用,当初它被用在HTTP 1.1规范的旧版本中. HTTP/1.1 可用
307 Temporary Redirect
(临时重定向)

服务器发送该响应用来引导客户端使用相同的方法访问另外一个URI来获取想要获取的资源.新的URL会在响应的Location:头字段里找到.与302状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST).

 HTTP/1.1 可用
308 Permanent Redirect
(永久重定向)

所请求的资源将永久的位于另外一个URI上.新的URL会在响应的Location:头字段里找到.与301状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST).

注意: 这是个试验性的状态码,这里是规范草案. Firefox14已经实现对该状态码的支持.

HTTPbis
(试验草案)
客户端错误
400 Bad Request
(错误请求)		 因发送的请求语法错误,服务器无法正常读取. HTTP/0.9 可用
401 Unauthorized
(未授权)		 需要身份验证后才能获取所请求的内容,类似于403错误.不同点是.401错误后,只要正确输入帐号密码,验证即可通过. HTTP/0.9 可用
402 Payment Required
(需要付款)		 该状态码被保留以供将来使用.创建此代码最初的目的是为数字支付系统而用,然而,到现在也没投入使用. HTTP/0.9 and 1.1
403 Forbidden
(禁止访问)		 客户端没有权利访问所请求内容,服务器拒绝本次请求. HTTP/0.9 可用
404 Not Found
(未找到)		 服务器找不到所请求的资源.由于经常发生此种情况,所以该状态码在上网时是非常常见的. HTTP/0.9 可用
405 Method Not Allowed
(不允许使用该方法)		 该请求使用的方法被服务器端禁止使用,RFC2616中规定, GET 和 HEAD 方法不能被禁止. HTTP/1.1 可用
406 Not Acceptable
(无法接受)		 在进行服务器驱动内容协商后,没有发现合适的内容传回给客户端. HTTP/1.1 可用
407 Proxy Authentication Required
(要求代理身份验证)

类似于状态码 401,不过需要通过代理才能进行验证.

 HTTP/1.1 可用
408 Request Timeout
(请求超时)		 客户端没有在服务器预备等待的时间内完成一个请求的发送.这意味着服务器将会切断和客户端的连接. 在其他浏览器中,这种响应更常见一些, 例如Chrome 和 IE9, 目的是为了使用 HTTP 预连机制 加快浏览速度 (查看{{ bug("634278") }}, Firefox在未来版本中会实现这种机制). 同时注意,一些服务器不发送此种响应就直接切断连接. HTTP/1.1 可用
409 Conflict
(冲突)		 该请求与服务器的当前状态所冲突. HTTP/1.1 可用
410 Gone
(已失效)		 所请求的资源已经被删除. HTTP/1.1 可用
411 Length Required
(需要内容长度头)		 因服务器在本次请求中需要 Content-Length 头字段,而客户端没有发送.所以,服务器拒绝了该请求. HTTP/1.1 可用
412 Precondition Failed
(预处理失败)		 服务器没能满足客户端在获取资源时在请求头字段中设置的先决条件. HTTP/1.1 可用
413 Request Entity Too Large
(请求实体过长)		 请求实体大小超过服务器的设置的最大限制,服务器可能会关闭HTTP链接并返回Retry-After 头字段. HTTP/1.1 可用
414 Request-URI Too Long
(请求网址过长)		 客户端请求所包含的URI地址太长,以至于服务器无法处理. HTTP/1.1 可用
415 Unsupported Media Type
(媒体类型不支持)		 服务器不支持客户端所请求的媒体类型,因此拒绝该请求. HTTP/1.1 可用
416 Requested Range Not Satisfiable
(请求范围不合要求)		 请求中包含的Range头字段无法被满足,通常是因为Range中的数字范围超出所请求资源的大小. HTTP/1.1 可用
417 Expectation Failed
(预期结果失败)		 在请求头 Expect 中指定的预期内容无法被服务器满足. HTTP/1.1 可用
服务器端错误
500 Internal Server Error
(内部服务器错误)		 服务器遇到未知的无法解决的问题. HTTP/0.9 可用
501 Implemented
(未实现)		 服务器不支持该请求中使用的方法,比如POST 和 PUT.只有GET 和 HEAD 是RFC2616规范中规定服务器必须实现的方法. HTTP/0.9 可用
502 Bad Gateway
(网关错误)		 服务器作为网关且从上游服务器获取到了一个无效的HTTP响应. HTTP/0.9 可用
503 Service Unavailable
(服务不可用)		 由于临时的服务器维护或者过载,服务器当前无法处理请求.这个状况是临时的,并且将在一段时间以后恢复.如果能够预计延迟时间,那么响应中可以包含一个Retry-After:头用以标明这个延迟时间.如果没有给出这个Retry-After:信息，那么客户端应当以处理500响应的方式处理它.同时,这种情况下,一个友好的用于解释服务器出现问题的页面应当被返回,并且,缓存相关的HTTP头信息也应该包含,因为通常这种错误提示网页不应当被客户端缓存. HTTP/0.9 可用
504 Gateway Timeout 
(网关超时)		 服务器作为网关且不能从上游服务器及时的得到响应返回给客户端. HTTP/1.1 可用
505 HTTP Version Not Supported
(HTTP版本不受支持)		 服务器不支持客户端发送的HTTP请求中所使用的HTTP协议版本. HTTP/1.1 可用 
+

 

+

{{ languages( { "en": "en/HTTP/HTTP_response_codes"} ) }}

-- cgit v1.2.3-54-g00ecf