seo达人 - 设计每日一贴---北京兰亭妙微/UI设计公司

032020-4

http的状态码（中英文）

seo达人

1**：请求收到，继续处理

2**：操作成功收到，分析、接受

3**：完成此请求必须进一步处理

4**：请求包含一个错误语法或不能完成

5**：服务器执行一个完全有效请求失败

100——客户必须继续发出请求

101——客户要求服务器根据请求转换HTTP协议版本

200——交易成功

201——提示知道新文件的URL

202——接受和处理、但处理未完成

203——返回信息不确定或不完整

204——请求收到，但返回信息为空

205——服务器完成了请求，用户代理必须复位当前已经浏览过的文件

206——服务器已经完成了部分用户的GET请求

300——请求的资源可在多处得到

301——删除请求数据

302——在其他地址发现了请求数据

303——建议客户访问其他URL或访问方式

304——客户端已经执行了GET，但文件未变化

305——请求的资源必须从服务器指定的地址得到

306——前一版本HTTP中使用的代码，现行版本中不再使用

307——申明请求的资源临时性删除

400——错误请求，如语法错误

401——请求授权失败

402——保留有效ChargeTo头响应

403——请求不允许

404——没有发现文件、查询或URl

405——用户在Request-Line字段定义的方法不允许

406——根据用户发送的Accept拖，请求资源不可访问

407——类似401，用户必须首先在代理服务器上得到授权

408——客户端没有在用户指定的饿时间内完成请求

409——对当前资源状态，请求不能完成

410——服务器上不再有此资源且无进一步的参考地址

411——服务器拒绝用户定义的Content-Length属性请求

412——一个或多个请求头字段在当前请求中错误

413——请求的资源大于服务器允许的大小

414——请求的资源URL长于服务器允许的长度

415——请求资源不支持请求项目格式

416——请求中包含Range请求头字段，在当前请求资源范围内没有range指示值，请求

也不包含If-Range请求头字段

417——服务器不满足请求Expect头字段指定的期望值，如果是代理服务器，可能是下

一级服务器不能满足请求

500——服务器产生内部错误

501——服务器不支持请求的函数

502——服务器暂时不可用，有时是为了防止发生系统过载

503——服务器过载或暂停维修

504——关口过载，服务器使用另一个关口或服务来响应用户，等待时间设定值较长

505——服务器不支持或拒绝支请求头中指定的HTTP版本

==========================================================

英文版：

100：Continue

101：Switching Protocols

102：Processing

200：OK

201：Created

202：Accepted

203：Non-Authoriative Information

204：No Content

205：Reset Content

206：Partial Content

207：Multi-Status

300：Multiple Choices

301：Moved Permanently

302：Found

303：See Other

304：Not Modified

305：Use Proxy

306：(Unused)

307：Temporary Redirect

400：Bad Request

401：Unauthorized

402：Payment Granted

403：Forbidden

404：File Not Found

405：Method Not Allowed

406：Not Acceptable

407：Proxy Authentication Required

408：Request Time-out

409：Conflict

410：Gone

411：Length Required

412：Precondition Failed

413：Request Entity Too Large

414：Request-URI Too Large

415：Unsupported Media Type

416：Requested range not satisfiable

417：Expectation Failed

422：Unprocessable Entity

423：Locked

424：Failed Dependency

500：Internal Server Error

501：Not Implemented

502：Bad Gateway

503：Service Unavailable

504：Gateway Timeout

505：HTTP Version Not Supported

507：Insufficient Storage

完整的 HTTP 1.1规范说明书来自于RFC 2616，你可以在rfc-editor在线查阅。HTTP 1.1的状态码被标记为新特性，因为许多浏览器只支持 HTTP 1.0。你应只把状态码发送给支持 HTTP 1.1的客户端，支持协议版本可以通过调用request.getRequestProtocol来检查。

本部分余下的内容会详细地介绍 HTTP 1.1中的状态码。这些状态码被分为五大类：

100-199 用于指定客户端应相应的某些动作。

200-299 用于表示请求成功。

300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。

400-499 用于指出客户端的错误。

500-599 用于支持服务器错误。

HttpServletResponse中的常量代表关联不同标准消息的状态码。在servlet程序中，你会更多地用到这些常量的标识来使用状态码。例如：你一般会使用response.setStatus(response.SC_NO_CONTENT)而不是 response.setStatus(204)，因为后者不易理解而且容易导致错误。但是，你应当注意到服务器允许对消息轻微的改变，而客户端只注意状态码的数字值。所以服务器可能只返回 HTTP/1.1 200 而不是 HTTP/1.1 200 OK。

100 (Continue/继续)

如果服务器收到头信息中带有100-continue的请求，这是指客户端询问是否可以在后续的请求中发送附件。在这种情况下，服务器用100(SC_CONTINUE)允许客户端继续或用417 (Expectation Failed)告诉客户端不同意接受附件。这个状态码是 HTTP 1.1中新加入的。

101 (Switching Protocols/转换协议)

101 (SC_SWITCHING_PROTOCOLS)状态码是指服务器将按照其上的头信息变为一个不同的协议。这是 HTTP 1.1中新加入的。

200 (OK/正常)

200 (SC_OK)的意思是一切正常。一般用于相应GET和POST请求。这个状态码对servlet是缺省的;如果没有调用setStatus方法的话，就会得到200。

201 (Created/已创建)

201 (SC_CREATED)表示服务器在请求的响应中建立了新文档;应在定位头信息中给出它的URL。

202 (Accepted/接受)

202 (SC_ACCEPTED)告诉客户端请求正在被执行，但还没有处理完。

203 (Non-Authoritative Information/非官方信息)

状态码203 (SC_NON_AUTHORITATIVE_INFORMATION)是表示文档被正常的返回，但是由于正在使用的是文档副本所以某些响应头信息可能不正确。这是 HTTP 1.1中新加入的。

204 (No Content/无内容)

在并没有新文档的情况下，204 (SC_NO_CONTENT)确保浏览器继续显示先前的文档。这各状态码对于用户周期性的重载某一页非常有用，并且你可以确定先前的页面是否已经更新。例如，某个servlet可能作如下操作：

int pageVersion =Integer.parseInt(request.getParameter("pageVersion"));

if (pageVersion >;= currentVersion) {

response.setStatus(response.SC_NO_CONTENT);

} else {

// Create regular page

}

但是，这种方法对通过刷新响应头信息或等价的HTML标记自动重载的页面起作用，因为它会返回一个204状态码停止以后的重载。但基于JavaScript脚本的自动重载在这种情况下仍然需要能够起作用。可以阅读本书7.2 ( HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1响应头信息以及他们的意义)部分的详细讨论。

205 (Reset Content/重置内容)

重置内容205 (SC_RESET_CONTENT)的意思是虽然没有新文档但浏览器要重置文档显示。这个状态码用于强迫浏览器清除表单域。这是 HTTP 1.1中新加入的。

206 (Partial Content/局部内容)

206 (SC_PARTIAL_CONTENT)是在服务器完成了一个包含Range头信息的局部请求时被发送的。这是 HTTP 1.1中新加入的。

300 (Multiple Choices/多重选择)

300 (SC_MULTIPLE_CHOICES)表示被请求的文档可以在多个地方找到，并将在返回的文档中列出来。如果服务器有首选设置，首选项将会被列于定位响应头信息中。

301 (Moved Permanently)

301 (SC_MOVED_PERMANENTLY)状态是指所请求的文档在别的地方;文档新的URL会在定位响应头信息中给出。浏览器会自动连接到新的URL。

302 (Found/找到)

与301有些类似，只是定位头信息中所给的URL应被理解为临时交换地址而不是永久的。注意：在 HTTP 1.0中，消息是临时移动(Moved Temporarily)的而不是被找到，因此HttpServletResponse中的常量是SC_MOVED_TEMPORARILY不是我们以为的SC_FOUND。

注意

代表状态码302的常量是SC_MOVED_TEMPORARILY而不是SC_FOUND。

状态码302是非常有用的因为浏览器自动连接在定为响应头信息中给出的新URL。这非常有用，而且为此有一个专门的方法——sendRedirect。使用response.sendRedirect(url)比调用response.setStatus(response.SC_MOVED_TEMPORARILY)和response.setHeader("Location", url)多几个好处。首先，response.sendRedirect(url)方法明显要简单和容易。第二，servlet自动建立一页保存这一连接以提供给那些不能自动转向的浏览器显示。最后，在servlet 2.2版本(J2EE中的版本)中，sendRedirect能够处理相对路径，自动转换为绝对路径。但是你只能在2.1版本中使用绝对路径。

如果你将用户转向到站点的另一页中，你要用 HttpServletResponse 中的 encodeURL 方法传送URL。这么做可预防不断使用基于URL重写的会话跟踪的情况。URL重写是一种在你的网站跟踪不使用 cookies 的用户的方法。这是通过在每一个URL尾部附加路径信息实现的，但是 servlet 会话跟踪API会自动的注意这些细节。会话跟踪在第九章讨论，并且养成使用 encodeURL 的习惯会使以后添加会话跟踪的功能更容易很多。

核心技巧

如果你将用户转向到你的站点的其他页面，用 response.sendRedirect(response.encodeURL(url)) 的方式事先计划好会话跟踪(session tracking)要比只是调用 response.sendRedirect(url) 好的多。

这个状态码有时可以与301交换使用。例如，如果你错误的访问了某路径信息不完整)，有些服务器就会回复301状态码而有些则回复302。从技术上说，如果最初的请求是GET浏览器只是被假定自动转向。如果想了解更多细节，请看状态码307的讨论。

303 (See Other/参见其他信息)

这个状态码和 301、302 相似，只是如果最初的请求是 POST，那么新文档(在定位头信息中给出)药用 GET 找回。这个状态码是新加入 HTTP 1.1中的。

304 (Not Modified/为修正)

当客户端有一个缓存的文档，通过提供一个 If-Modified-Since 头信息可指出客户端只希望文档在指定日期之后有所修改时才会重载此文档，用这种方式可以进行有条件的请求。304 (SC_NOT_MODIFIED)是指缓冲的版本已经被更新并且客户端应刷新文档。另外，服务器将返回请求的文档及状态码 200。servlet一般情况下不会直接设置这个状态码。它们会实现getLastModified方法并根据修正日期让默认服务方法处理有条件的请求。这个方法的例程已在2.8部分(An Example Using Servlet Initialization and Page Modification Dates/一个使用servlet初始化和页面修正日期的例子)给出。

305 (Use Proxy/使用代理)

305 (SC_USE_PROXY)表示所请求的文档要通过定位头信息中的代理服务器获得。这个状态码是新加入 HTTP 1.1中的。

307 (Temporary Redirect/临时重定向)

浏览器处理307状态的规则与302相同。307状态被加入到 HTTP 1.1中是由于许多浏览器在收到302响应时即使是原始消息为POST的情况下仍然执行了错误的转向。只有在收到303响应时才假定浏览器会在POST请求时重定向。添加这个新的状态码的目的很明确：在响应为303时按照GET和POST请求转向;而在307响应时则按照GET请求转向而不是POST请求。注意：由于某些原因在HttpServletResponse中还没有与这个状态对应的常量。该状态码是新加入HTTP 1.1中的。

注意

在 HttpServletResponse 中没有 SC_TEMPORARY_REDIRECT 常量，所以你只能显示的使用307状态码。

400 (Bad Request/错误请求)

400 (SC_BAD_REQUEST)指出客户端请求中的语法错误。

401 (Unauthorized/未授权)

401 (SC_UNAUTHORIZED)表示客户端在授权头信息中没有有效的身份信息时访问受到密码保护的页面。这个响应必须包含一个WWW-Authenticate的授权信息头。例如，在本书4.5部分中的“Restricting Access to Web Pages./限制访问Web页。”

403 (Forbidden/禁止)

403 (SC_FORBIDDEN)的意思是除非拥有授权否则服务器拒绝提供所请求的资源。这个状态经常会由于服务器上的损坏文件或目录许可而引起。

404 (Not Found/未找到)

404 (SC_NOT_FOUND)状态每个网络程序员可能都遇到过，他告诉客户端所给的地址无法找到任何资源。它是表示“没有所访问页面”的标准方式。这个状态码是常用的响应并且在HttpServletResponse类中有专门的方法实现它：sendError("message")。相对于setStatus使用sendError得好处是：服务器会自动生成一个错误页来显示错误信息。但是，Internet Explorer 5浏览器却默认忽略你发挥的错误页面并显示其自定义的错误提示页面，虽然微软这么做违反了 HTTP 规范。要关闭此功能，在工具菜单里，选择Internet选项，进入高级标签页，并确认“显示友好的 HTTP 错误信息”选项(在我的浏览器中是倒数第8各选项)没有被选。但是很少有用户知道此选项，因此这个特性被IE5隐藏了起来使用户无法看到你所返回给用户的信息。而其他主流浏览器及IE4都完全的显示服务器生成的错误提示页面。可以参考图6-3及6-4中的例子。

核心警告

默认情况下，IE5忽略服务端生成的错误提示页面。

405 (Method Not Allowed/方法未允许)

405 (SC_METHOD_NOT_ALLOWED)指出请求方法(GET, POST, HEAD, PUT, DELETE, 等)对某些特定的资源不允许使用。该状态码是新加入 HTTP 1.1中的。

406 (Not Acceptable/无法访问)

406 (SC_NOT_ACCEPTABLE)表示请求资源的MIME类型与客户端中Accept头信息中指定的类型不一致。见本书7.2部分中的表7.1(HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1响应头信息以及他们的意义)中对MIME类型的介绍。406是新加入 HTTP 1.1中的。

407 (Proxy Authentication Required/代理服务器认证要求)

407 (SC_PROXY_AUTHENTICATION_REQUIRED)与401状态有些相似，只是这个状态用于代理服务器。该状态指出客户端必须通过代理服务器的认证。代理服务器返回一个Proxy-Authenticate响应头信息给客户端，这会引起客户端使用带有Proxy-Authorization请求的头信息重新连接。该状态码是新加入 HTTP 1.1中的。

408 (Request Timeout/请求超时)

408 (SC_REQUEST_TIMEOUT)是指服务端等待客户端发送请求的时间过长。该状态码是新加入 HTTP 1.1中的。

409 (Conflict/冲突)

该状态通常与PUT请求一同使用，409 (SC_CONFLICT)状态常被用于试图上传版本不正确的文件时。该状态码是新加入 HTTP 1.1中的。

410 (Gone/已经不存在)

410 (SC_GONE)告诉客户端所请求的文档已经不存在并且没有更新的地址。410状态不同于404，410是在指导文档已被移走的情况下使用，而404则用于未知原因的无法访问。该状态码是新加入 HTTP 1.1中的。

411 (Length Required/需要数据长度)

411 (SC_LENGTH_REQUIRED)表示服务器不能处理请求(假设为带有附件的POST请求)，除非客户端发送Content-Length头信息指出发送给服务器的数据的大小。该状态是新加入 HTTP 1.1的。

412 (Precondition Failed/先决条件错误)

412 (SC_PRECONDITION_FAILED)状态指出请求头信息中的某些先决条件是错误的。该状态是新加入 HTTP 1.1的。

413 (Request Entity Too Large/请求实体过大)

413 (SC_REQUEST_ENTITY_TOO_LARGE)告诉客户端现在所请求的文档比服务器现在想要处理的要大。如果服务器认为能够过一段时间处理，则会包含一个Retry-After的响应头信息。该状态是新加入 HTTP 1.1的。

414 (Request URI Too Long/请求URI过长)

414 (SC_REQUEST_URI_TOO_LONG)状态用于在URI过长的情况时。这里所指的“URI”是指URL中主机、域名及端口号之后的内容。该状态是新加入 HTTP 1.1的。

415 (Unsupported Media Type/不支持的媒体格式)

415 (SC_UNSUPPORTED_MEDIA_TYPE)意味着请求所带的附件的格式类型服务器不知道如何处理。该状态是新加入 HTTP 1.1的。

416 (Requested Range Not Satisfiable/请求范围无法满足)

416表示客户端包含了一个服务器无法满足的Range头信息的请求。该状态是新加入 HTTP 1.1的。奇怪的是，在servlet 2.1版本API的HttpServletResponse中并没有相应的常量代表该状态。

注意

在servlet 2.1的规范中，类HttpServletResponse并没有SC_REQUESTED_RANGE_NOT_SATISFIABLE 这样的常量，所以你只能直接使用416。在servlet 2.2版本之后都包含了此常量。

417 (Expectation Failed/期望失败)

如果服务器得到一个带有100-continue值的Expect请求头信息，这是指客户端正在询问是否可以在后面的请求中发送附件。在这种情况下，服务器也会用该状态(417)告诉浏览器服务器不接收该附件或用100 (SC_CONTINUE)状态告诉客户端可以继续发送附件。该状态是新加入 HTTP 1.1的。

500 (Internal Server Error/内部服务器错误)

500 (SC_INTERNAL_SERVER_ERROR) 是常用的“服务器错误”状态。该状态经常由CGI程序引起也可能(但愿不会如此!)由无法正常运行的或返回头信息格式不正确的servlet引起。

501 (Not Implemented/未实现)

501 (SC_NOT_IMPLEMENTED)状态告诉客户端服务器不支持请求中要求的功能。例如，客户端执行了如PUT这样的服务器并不支持的命令。

502 (Bad Gateway/错误的网关)

502 (SC_BAD_GATEWAY)被用于充当代理或网关的服务器;该状态指出接收服务器接收到远端服务器的错误响应。

503 (Service Unavailable/服务无法获得)

状态码503 (SC_SERVICE_UNAVAILABLE)表示服务器由于在维护或已经超载而无法响应。例如，如果某些线程或数据库连接池已经没有空闲则servlet会返回这个头信息。服务器可提供一个Retry-After头信息告诉客户端什么时候可以在试一次。

504 (Gateway Timeout/网关超时)

该状态也用于充当代理或网关的服务器;它指出接收服务器没有从远端服务器得到及时的响应。该状态是新加入 HTTP 1.1的。

505 (HTTP Version Not Supported/不支持的 HTTP 版本)

505 (SC_HTTP_VERSION_NOT_SUPPORTED)状态码是说服务器并不支持在请求中所标明 HTTP 版本。该状态是新加入 HTTP 1.1的。

评论(0) 浏览(2893)

022020-4

常见的HTTP状态码

seo达人

HTTP状态码

HTTP状态码（英语：HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。除非另有说明，状态码是HTTP / 1.1标准（RFC 7231）的一部分。

HTTP状态码的官方注册表由互联网号码分配局（Internet Assigned Numbers Authority）维护。

微软互联网信息服务（Microsoft Internet Information Services）有时会使用额外的十进制子代码来获取更多具体信息，但是这些子代码仅出现在响应有效内容和文档中，而不是代替实际的HTTP状态代码。

HTTP状态码分类

分类分类描述

1 信息，服务器收到请求，需要请求者继续执行操作

2 成功，操作被成功接收并处理

3 重定向，需要进一步的操作以完成请求

4 客户端错误，请求包含语法错误或无法完成请求

5** 服务器错误，服务器在处理请求的过程中发生了错误

1xx 信息（消息）

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

100 Continue

继续。客户端应当继续发送请求。

101 Switching Protocols

切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议。

2xx 成功

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

200 OK

请求成功。请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。

201 Created

已创建。成功请求并创建了新的资源。

202 Accepted

已接受。已经接受请求，但未处理完成。

203 Non-Authoritative Information

非授权信息。请求成功，但返回的meta信息不在原始的服务器，而是一个副本。

204 No Content

无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。

205 Reset Content

重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域。

206 Partial Content

部分内容。服务器成功处理了部分GET请求，类似于 FlashGet 或者迅雷这类的 HTTP下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。

3xx 重定向

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

当且仅当后续的请求所使用的方法是 GET 或者 HEAD 时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A->A，或者A->B->C->A），因为这会导致服务器和客户端大量不必要的资源消耗。按照 HTTP/1.0 版规范的建议，浏览器不应自动访问超过5次的重定向。

300 Multiple Choices

多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择。

301 Moved Permanently

永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。

302 Move Temporarily（Found）

临时移动。与301类似，但资源只是临时被移动，客户端应继续使用原有URI。

303 See Other

查看其它地址。与301类似，使用GET和POST请求查看。

304 Not Modified

未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。

305 Use Proxy

使用代理。所请求的资源必须通过代理访问。

306 Switch Proxy

在版的规范中，306状态码已经不再被使用。它算是已经被废弃的HTTP状态码。

307 Temporary Redirect

临时重定向。与302类似，使用GET请求重定向。

4xx 客户端错误（请求错误）

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。

400 Bad Request

客户端请求的语法错误，服务器无法理解。

401 Unauthorized

当前请求需要用户验证。

402 Payment Required

该状态码是为了将来可能的需求而预留的。（保留，将来使用。）

403 Forbidden

服务器理解请求客户端的请求，但是拒绝执行此请求。

404 Not Found

请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。出现这个错误的最有可能的原因是服务器端没有这个页面。

405 Method Not Allowed

客户端请求中的方法被禁止，也就是请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。

406 Not Acceptable

服务器无法根据客户端请求的内容特性完成请求，也就是请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。

407 Proxy Authentication Required

与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。

408 Request Timeout

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

409 Conflict

由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。

冲突通常发生于对 PUT 请求的处理中。例如，在采用版本检查的环境下，某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。

410 Gone

客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置。

411 Length Required

服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后，客户端可以再次提交该请求。

412 Precondition Failed

客户端请求信息的先决条件错误，也就是服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。

413 Request Entity Too Large

服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的，服务器应当返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long

请求的URI过长（URI通常为网址），服务器无法处理。

415 Unsupported Media Type

服务器无法处理请求附带的媒体格式，也就是对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。

416 Requested Range Not Satisfiable

客户端请求的范围无效，也就是如果请求中包含了 Range 请求头，并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义 If-Range 请求头，那么服务器就应当返回416状态码。

417 Expectation Failed

服务器无法满足Expect的请求头信息，也就是在请求头 Expect 中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect 的内容无法被满足。

5xx 服务器错误

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。

500 Internal Server Error

服务器内部错误，无法完成请求。服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。

501 Not Implemented

服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。

502 Bad Gateway

作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应。

503 Service Unavailable

由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。

注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。

504 Gateway Timeout

作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

505 HTTP Version Not Supported

服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

感谢观看！

参考资料：

https://www.runoob.com/http/http-status-codes.html

若想了解更多请参考：

HTTP状态码百度百科

https://blog.csdn.net/GarfieldEr007/article/details/77984065

评论(0) 浏览(2362)

012020-4

学渣代表HTML知识基础语法篇

seo达人

HTML基础知识

第一篇，HTML的结构

HTML中两个概念

(1).HTML标签：<元素名称></元素名称>

完整语法：<元素名称>要控制的元素</元素名称>

HTML标签分为两种：成对：只对标签内的元素起作用

单独：在相应位置插入换行

标签属性设置在元素的首标签：语法：<元素属性1=“值1” …>元素资料</元素>,""可省略

HTML元素：一组标签将一段文字包含在中间，这一组标签与文字就是元素

结构

在所有的HTML文件中最外层由标签建立，并包含两个子标签：元素为文件标题：元素为文件主题

：说明文件标题和文件的一些公共属性：文件主体

<!DOCTYPE html>

<html>

<head>

<meta charset="utf-8">

<title>HTML结构</title>

</head>

<body>

Hellow Word！

</body>

</html>

评论(0) 浏览(3029)

312020-3

SS之盒子模型与背景属性————每天一遍小知识

seo达人

盒子模型与背景属性

一.盒子模型

1.介绍

元素的总宽度和总高度

二.自定义边框——border

1.基本设置

2.边框宽度——Border Width

3.边框颜色——Border Color

4.边框样式——Border style

5.CSS的边宽和高度——width height

三.背景——background

1.背景颜色——background color

2.背景图像—— background image

3.背景重复—— background repeat

4.背景的附件（固定与滚动）——background attachment

一.盒子模型

1.介绍

所有HTML元素都可以视为方框。

CSS边框模型代表网站的设计和布局。

它由边缘（margins），边框（ borders），内边距（paddings），和内容（content）组成的。

这些属性以什么的顺序工作：top->right->bottom->left。

小知识：

网页的每个元素都是一个盒子（box）。 CSS使用盒子模型来确定盒子有多大以及如何放置它们。

框模型还用于计算HTML元素的实际宽度和高度。
元素的总宽度和总高度

（1）总宽度等于左右边缘，边框，边距相加：

（2）总高度：上下相加

二.自定义边框——border

1.基本设置

border属性允许您自定义HTML元素的边框。

为了向元素添加边框，您需要指定边框的大小，样式，颜色。

p {

padding: 10px;

border: 5px solid green;

}

2.边框宽度——Border Width

使用border-width属性可以单独设置边框宽度

p{

padding: 10px;

border-style: solid;

border-width: 2px;

}

3.边框颜色——Border Color

可以使用颜色名称，RGB或十六进制值定义元素的边框颜色。

p.first {

padding: 10px;

border-style: solid;

border-width: 2px;

border-color: blue;

}

小知识：除非设置border-style属性，否则所有border属性都不会起作用。

4.边框样式——Border style

默认值为none

多种样式：dotted（点）, dashed（虚线）, double（双边框）等。

p {border-style: none;}

p {border-style: dotted;}

p{border-style: dashed;}

p{border-style: double;}

p {border-style: groove;}

p {border-style: ridge;}

p{border-style: inset;}

p{border-style: outset;}

p {border-style: hidden;}

5.CSS的边宽和高度——width height

要设置<div>元素的总宽度和高度为100px：

div {

border: 5px solid green;

width: 90px;

height: 90px;

}

框的总宽度和高度将为90px + 5px（边框）+ 5px（边框）= 100px；

可以使用百分比进行分配。

div {

border: 5px solid green;

width: 100%;

height: 90px;

}

3.要设置元素的最小和最大高度与宽度，可以使用以下属性：

min-width-元素的最小宽度

min-height-元素的最小高度

max-width-元素的最大宽度

max-height-元素的最大高度

p{

border: 5px solid green;

min-height: 100px;

}

三.背景——background

1.背景颜色——background color

background-color属性用来指定一个元素的背景色。

列：

body {

background-color: #C0C0C0;

}

h1 {

background-color: rgb(135,206,235);

}

p {

background-color: LightGreen;

}

2.背景图像—— background image

background-image属性中的元素可以设置一个或几个背景图像。

URL指定路径的图像文件。相对路径和绝对路径均受支持。

默认情况下，背景图像放置在元素的左上角，并在垂直和水平方向重复以覆盖整个元素。

列;为元素设置背景图片。

p {

padding: 30px;

background-image: url("1.jpg");

color: white;

}

小知识

要指定多个图像，只需用逗号分隔URL。

3.背景重复—— background repeat

repeat-x：图片延x轴复制

repeat-y：图片延y轴复制

Inherited：继承父级属性相同的指定值

no-repeat:不重复，只有单个图片

列：

body {

background-image: url("1.png");

background-repeat: repeat-x;

}

p {

background-image: url("1.png");

background-repeat: inherit;

margin-top: 100px;

padding: 40px;

}

4.背景的附件（固定与滚动）——background attachment

有效值

fixed：固定背景图片

scroll：向下滚动页面是，背景也随着滚动

Inherit：继承

列：

body {

background-image: url("1.png");

background-repeat: no-repeat;

background-attachment: scroll;

}

评论(0) 浏览(3126)

302020-3

Swift 闭包简单使用

seo达人

在Swift开发文档中是这样介绍闭包的：闭包是可以在你的代码中被传递和引用的功能性独立模块。

Swift闭包

闭包的形式

Swift中的闭包有很多优化的地方

创建基本的闭包

在闭包中接收参数

从闭包中返回值

闭包作为参数

尾随闭包语法

值捕获

逃逸闭包

闭包的形式

全局函数嵌套函数闭包表达式

有名字但不能捕获任何值。有名字，也能捕获封闭函数内的值。无名闭包，使用轻量级语法，可以根据上下文环境捕获值。

Swift中的闭包有很多优化的地方

根据上下文推断参数和返回值类型

从单行表达式闭包中隐式返回（也就是闭包体只有一行代码，可以省略return）

可以使用简化参数名，如$0, $1(从0开始，表示第i个参数…)

提供了尾随闭包语法(Trailing closure syntax)

闭包是引用类型：无论你将函数或闭包赋值给一个常量还是变量，你实际上都是将常量或变量的值设置为对应函数或闭包的引用

创建基本的闭包

let bibao = {

print("我要创建闭包")

}

上面的代码实际上创建了一个匿名的函数，并将这个函数赋给了 driving。之后你就可以把 driving() 当作一个常规的函数来用，就像这样：

bibao()

在闭包中接收参数

当你创建闭包的时候，它们并没有名字，也没有提供书写参数的地方。但这并不意味着它们不能接收参数，只不过它们接收参数的方式稍有不同：这些参数是被写在花括号里面的。

为了让一个闭包接收参数，你需要在花括号之后把这些参数列出来，然后跟上一个 in 关键字。这样就告诉Swift，闭包的主体是从哪里开始的。

举个例子，我们来创建一个闭包，接收一个叫 place 的字符串作为唯一的参数，就像这样：

let bibao= { (bao1: String) in

print("我要创建 (bao1)。")

}

函数和闭包的一个区别是运行闭包的时候你不会用到参数标签。因此，调用 driving() 的时候，我们是这样写的：

bibao("闭包")

从闭包中返回值

闭包也能返回值，写法和闭包的参数类似：写在闭包内部， in 关键字前面。

还是以 driving() 闭包为例，让它返回一个字符串。原来的函数是这样的：

let bibao= { (bao1: String) in

print("我要创建 (bao1)。")

}

改成返回字符串而不是直接打印那个字符串，需要 in 之前添加 -> String，然后像常规函数那样用到 return 关键字:

let drivingWithReturn = { (bao1: String) -> String in

return "我要创建 (bao1)。"

}

现在我们运行这个闭包并且打印出它的返回值：

let message = drivingWithReturn("闭包")

print(message)

闭包作为参数

既然闭包可以像字符串和整数一样使用，你就可以将它们传入函数。闭包作为参数的语法乍一看一看挺伤脑筋的，让我们慢慢来。

首先，还是基本的 driving() 闭包。

let driving = {

print("我正在创建")

}

如果我们打算把这个闭包传入一个函数，以便函数内部可以运行这个闭包。我们需要把函数的参数类型指定为 () -> Void。它的意思是“不接收参数，并且返回 Void”。在Swift中，Void是什么也没有的意思。

好了，让我们来写一个 travel() 函数，接收不同类型的 traveling 动作，并且在动作前后分别打印信息：

func travel(action: () -> Void) {

print("我准备创建")

action()

print("我建好了")

}

现在可以用上 driving 闭包了，就像这样：

travel(action: driving)

1

尾随闭包语法

如果一个函数的最后一个参数是闭包，Swift允许你采用一种被称为 “拖尾闭包语法” 的方式来调用这个闭包。你可以把闭包传入函数之后的花括号里，而不必像传入参数那样。

又用到我们的 travel() 函数了。它接收一个 action 闭包。闭包在两个 print() 调用之间执行:

func travel(action: () -> Void) {

print("我准备创建")

action()

print("我建好了")

}

由于函数的最后一个参数是闭包，我们可以用拖尾闭包语法来调用 travel() 函数，就像这样：

travel() {

print("我要创建闭包")

}

实际上，由于函数没有别的参数了，我们还可以将圆括号完全移除：

travel {

print("我要创建闭包")

}

拖尾闭包语法在Swift中非常常见，所以要加深印象。

值捕获

闭包可以在其被定义的上下文中捕获常量或变量。即使定义这些常量和变量的原作用域已经不存在，闭包仍然可以在闭包函数体内引用和修改这些值。

Swift 中，可以捕获值的闭包的最简单形式是嵌套函数，也就是定义在其他函数的函数体内的函数。嵌套函数可以捕获其外部函数所有的参数以及定义的常量和变量。

官方文档例子：

func makeIncrementer(forIncrement amount: Int) -> () -> Int {

var runningTotal = 0

func incrementer() -> Int {

runningTotal += amount

return runningTotal

}

return incrementer

}

//运行结果：

let one = makeIncrementer(forIncrement: 10)

print(one()) //10

print(one()) //20

let two = makeIncrementer(forIncrement: 10)

print(two()) //10

print(two()) //20

逃逸闭包

当一个闭包作为参数传到一个函数中，但是这个闭包在函数返回之后才被执行，我们称该闭包从函数中逃逸。当你定义接受闭包作为参数的函数时，你可以在参数名之前标注 @escaping，用来指明这个闭包是允许“逃逸”出这个函数的。（默认值：@noescaping）

官方文档例子：

var completionHandlers: [() -> Void] = []

func someFunctionWithEscapingClosure(completionHandler: @escaping () -> Void) {

completionHandlers.append(completionHandler)

}

如上面例子，加入标注@escaping即可表明这个闭包是允许逃逸的

以上就是我对Swift闭包的浅薄认知，如果有细节错误请指出，也可以查阅官方文档，链接在下面教程更为详细。

就是这样啦，爱你们么么么~~

评论(0) 浏览(3301)

292020-3

Vue中如何监控某个属性值的变化

seo达人

Vue中如何监控某个属性值的变化？

比如现在需要监控data中，obj.a 的变化。Vue中监控对象属性的变化你可以这样：

watch: {

obj: {

handler (newValue, oldValue) {

console.log('obj changed')

},

deep: true

}

}

deep属性表示深层遍历，但是这么写会监控obj的所有属性变化，并不是我们想要的效果，所以做点修改：

watch: {

'obj.a': {

handler (newName, oldName) {

console.log('obj.a changed')

}

}

}

还有一种方法，可以通过computed 来实现，只需要：

computed: {

a1 () {

return this.obj.a

}

}

利用计算属性的特性来实现，当依赖改变时，便会重新计算一个新值。

评论(0) 浏览(3987)

262020-3

你不知道的--save-dev和--save的区别

seo达人

网上对于这两个的区别解释都是统一口径的，一个是开发依赖，一个是线上依赖，打包发布需要用到的要添加到线上依赖，一模一样的回答，误导了很多人。今天自己测试一下这两个命令，记录一下。

–save-dev，会在devDependencies里面添加依赖

-D，会在devDependencies里面添加依赖

–save，会在dependencies里面添加依赖

-S，会在dependencies里面添加依赖

devDependencies和dependencies可以同时存在同一个包的依赖。

如果npm install xxx后面没有输入要保存到哪个里面，devDependencies和dependencies都没有。

我这边直接npm install jquery，node_modules下有jQuery。然后我删除node_modules,执行npm install，node_modules下并没有下载jQuery。

所以，安装依赖的时候如果没有加上要依赖到开发还是线上，只是临时的在node_modules里面帮你下载，而devDependencies和dependencies的依赖都会帮你下载。

然后我在devDependencies下安装依赖：

"devDependencies": {

"html-webpack-plugin": "^4.0.3",

"jquery": "^3.4.1",

"webpack": "^4.42.1",

"webpack-cli": "^3.3.11"

}

在入口文件引用和打印jQuery：

import $ from 'jquery'

console.log($)

打包之后，可以使用jQuery。

然后我在dependencies下安装依赖：

"dependencies": {

"html-webpack-plugin": "^4.0.3",

"jquery": "^3.4.1",

"webpack": "^4.42.1",

"webpack-cli": "^3.3.11"

}

在入口文件引用和打印jQuery：

import $ from 'jquery'

console.log($)

打包之后，可以使用jQuery。

测试的结果就是，无论是–save还是–save-dev，对于打包都没有任何影响。devDependencies和dependencies两种情况，打包出来的main.js都把jQuery打包进去。这两种情况，如果都没有引用jQuery的情况下，也都不会把jQuery打包。

接着在一个空白的项目里面下载axios,npm install axios -S,打开node_modules文件夹：

发现多出了另外三个依赖，查看axios下的package.json：

"dependencies": {

"follow-redirects": "1.5.10"

}

查看follow-redirects下的package.json：

"dependencies": {

"debug": "=3.1.0"

}

查看debugs下的package.json：

"dependencies": {

"ms": "2.0.0"

}

最后ms的package.json没有dependencies。

而这几个包的devDependencies依赖的包没有一个下载。

接着我在node_modules把follow-redirects、debugs、ms都删了，把axios里面的package.js的dependencies给删了，然后执行npm install,发现没有下载follow-redirects、debugs、ms这几个，也证明了如果node_modules里面有下载的包，是不会重新去下载的。我把node_modules删除，执行npm install，这几个包又都下载下来了。

最后得出的结论是，–save-dev和–save在平时开发的时候，对于打包部署上线是没有任何影响的。如果你是发布一个包给别人用，而你开发的包依赖第三方的包，那么你如果是–save，那么别人安装你开发的包，会默认下载你依赖的包，如果你是–save-dev，那么别人安装你开发的包，是不会默认帮忙下载你依赖的包。

其实发布的包如果没有必要，很少会默认帮你下载，比如bootstrap，依赖jQuery，怕你原本就下载了引起冲突，也不会在dependencies里面安装jQuery而是：

"peerDependencies": {

"jquery": "1.9.1 - 3",

"popper.js": "^1.16.0"

}

表示bootstrap依赖于这两个包，你必须安装，版本不固定，但是一定要安装这两个包，安装的时候会有警告：

peerDependencies WARNING bootstrap@ requires a peer of jquery@1.9.1 - 3 but none was installed

peerDependencies WARNING bootstrap@ requires a peer of popper.js@^1.16.0 but none was installed

当你引用了然后打包，报错：

ERROR in ./node_modules/_bootstrap@4.4.1@bootstrap/dist/js/bootstrap.js

Module not found: Error: Can't resolve 'jquery' in 'C:\Users\wade\Desktop\savedev\node_modules_bootstrap@4.4.1@bootstrap\dist\js'

@ ./node_modules/_bootstrap@4.4.1@bootstrap/dist/js/bootstrap.js 7:82-99

@ ./src/index.js

ERROR in ./node_modules/_bootstrap@4.4.1@bootstrap/dist/js/bootstrap.js

Module not found: Error: Can't resolve 'popper.js' in 'C:\Users\wade\Desktop\savedev\node_modules_bootstrap@4.4.1@bootstrap\dist\js'

@ ./node_modules/_bootstrap@4.4.1@bootstrap/dist/js/bootstrap.js 7:101-121

@ ./src/index.js

以上就是对–save和–save-dev的一些测试，想更快的得出结论其实是自己发布一个包。至于本人的答案是不是存在错误，欢迎指出，因为只是自己简单测试的结果。

评论(0) 浏览(2953)

242020-3

node 模块简述

seo达人

Node 的os模块是操作系统的

Node 的内置模块 fs

内置模块在下载node的时候就自带的，使用 require（）方法来导入

语法：require(‘模块fs’)

在内置模块中的方法

1 fs.readFile（） —》用来专门异步读取文件的方法三个参数

语法：fs.readFile(‘要读取的文件’，读取文件的格式，读取成功的回调函数)

Eg : fs.readFIle(‘a’,’utf8’,’function(err,data){ })

2 fs.readFileSync()-– 专门用来同步读取的方法，两个参数

语法： fs.readFileSync(‘要读取的文件’，读取格式)

3 fs.writeFIle() —>用来写入异步文件的方法三个参数

语法： fs.writeFile(‘写入到哪个文件’，写入的内容，成功的回调函数)

Eg: fs.writeFile(‘./text.tex’,”内容”， function(){ })

注意：再次写入的内容会完全覆盖。如果文件夹没有会自动创建一个文件夹

4 fs.writeFileSync() --> 同步写入的方法

语法： fs.writeFileSync(‘写入到文件’，“写入的内容”)

Node的http模块

这个模块专门用来创建服务的

只能支持http协议。

也是使用require（）方法

Const http= require(“http”)

方法

1 http.createServer(function(req,res){ }) 两个形参

Req=request 代表每次的请求信息

Res=response 代表每次请求的响应

返回值是一个服务，当服务监听端口号的时候，就变成了服务器。

2 监听端口号

创建的服务.listen(监听的端口号，监听成功的回调函数（选填）)

server.listen(8080,function(){ 端口号0-65535 建议0-1023不使用 })

此时浏览器就可以执行localhost进行访问了

自定义模块

每一个js文件都是一个独立的模块，他们都自带一个 module 是一个对象，

其中 module里面的 exports,是一个对象这个 module.exports 就是这个文件向外导出的内容，也就是说，只有导出，才能导入

Eg: function fn1（）{console.log() }

Module.exports.fn1=fn1

这样，才能是另一个js文件到入这个文件同样也是require(‘./js’)方法

评论(0) 浏览(2993)

232020-3

NodeJS服务总是崩溃的解决办法

seo达人

许多人都有这样一种映像，NodeJS比较快；但是因为其是单线程，所以它不稳定，有点不安全，不适合处理复杂业务；它比较适合对并发要求比较高，而且简单的业务场景。

在Express的作者的TJ Holowaychuk的告别Node.js一文中列举了以下罪状：

Farewell NodeJS (TJ Holowaychuk)

•   you may get duplicate callbacks
•   you may not get a callback at all (lost in limbo)
•   you may get out-of-band errors
•   emitters may get multiple “error” events
•   missing “error” events sends everything to hell
•   often unsure what requires “error” handlers
•   “error” handlers are very verbose
•   callbacks suck

其实这几条主要吐嘈了两点： node.js错误处理很扯蛋，node.js的回调也很扯蛋。

事实上呢？

事实上NodeJS里程确实有“脆弱”的一面，单线程的某处产生了“未处理的”异常确实会导致整个Node.JS的崩溃退出，来看个例子, 这里有一个node-error.js的文件：

var http = require(＇http＇);

var server = http.createServer(function (req, res) {

  //这里有个错误，params 是 undefined
  var ok = req.params.ok;

  res.writeHead(200, {＇Content-Type＇: ＇text/plain＇});
  res.end(＇Hello World
＇);
});

server.listen(8080, ＇127.0.0.1＇);

console.log(＇Server running at http://127.0.0.1:8080/＇);

启动服务，并在地址栏测试一下发现 http://127.0.0.1:8080/ 不出所料，node崩溃了

$ node node-error
Server running at http://127.0.0.1:8080/

c:githubscript
ode-error.js:5
  var ok = req.params.ok;
                     ^
TypeError: Cannot read property ＇ok＇ of undefined
    at Server.<anonymous> (c:githubscript
ode-error.js:5:22)
    at Server.EventEmitter.emit (events.js:98:17)
    at HTTPParser.parser.onIncoming (http.js:2108:12)
    at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23)
    at Socket.socket.ondata (http.js:1966:22)
    at TCP.onread (net.js:525:27)

怎么解决呢？

其实Node.JS发展到今天，如果连这个问题都解决不了，那估计早就没人用了。

使用uncaughtException

我们可以uncaughtException来全局捕获未捕获的Error，同时你还可以将此函数的调用栈打印出来，捕获之后可以有效防止node进程退出，如：

process.on(＇uncaughtException＇, function (err) {
  //打印出错误
  console.log(err);
  //打印出错误的调用栈方便调试
  console.log(err.stack)；
});

这相当于在node进程内部进行守护，但这种方法很多人都是不提倡的，说明你还不能完全掌控Node.JS的异常。

使用 try/catch

我们还可以在回调前加try/catch，同样确保线程的安全。

var http = require(＇http＇);

http.createServer(function(req, res) {
  try {
    handler(req, res);
  } catch(e) {
    console.log(＇
＇, e, ＇
＇, e.stack);
    try {
      res.end(e.stack);
    } catch(e) { }
  }
}).listen(8080, ＇127.0.0.1＇);

console.log(＇Server running at http://127.0.0.1:8080/＇);

var handler = function (req, res) {
  //Error Popuped
  var name = req.params.name;

  res.writeHead(200, {＇Content-Type＇: ＇text/plain＇});
  res.end(＇Hello ＇ + name);
};

这种方案的好处是，可以将错误和调用栈直接输出到当前发生的网页上。

集成到框架中

标准的HTTP响应处理会经历一系列的Middleware（HttpModule），最终到达Handler，如下图所示：

这些Middleware和Handler在NodeJS中都有一个特点，他们都是回调函数，而回调函数中是唯一会让Node在运行时崩溃的地方。根据这个特点，我们只需要在框架中集成一处try/catch就可以相对完美地解决异常问题，而且不会影响其它用户的请求request。

事实上现在的NodeJS WEB框架几乎都是这么做的，如 OurJS开源博客所基于的 WebSvr

就有这么一处异常处理代码：

Line: 207

  try {
    handler(req, res);
  } catch(err) {
    var errorMsg
      = ＇
＇
      + ＇Error ＇ + new Date().toISOString() + ＇ ＇ + req.url
      + ＇
＇
      + err.stack || err.message || ＇unknow error＇
      + ＇
＇
      ;

    console.error(errorMsg);
    Settings.showError
      ? res.end(＇<pre>＇ + errorMsg + ＇</pre>＇)
      : res.end();
  }

那么不在回调中产生的错误怎么办？不必担心，其实这样的node程序根本就起不起来。

此外node自带的 cluster 也有一定的容错能力，它跟nginx的worker很类似，但消耗资源（内存）略大，编程也不是很方便，OurJS并没有采用此种设计。

守护NodeJS进程和记录错误日志

现在已经基本上解决了Node.JS因异常而崩溃的问题，不过任何平台都不是100%可靠的，还有一些错误是从Node底层抛出的，有些异常 try/catch和uncaughtException都无法捕获。之前在运行ourjs的时侯，会偶尔碰到底层抛出的文件流读取异常，这就是一个底层 libuv的BUG，node.js在0.10.21中进行了修复。

面对这种情况，我们就应该为nodejs应用添加守护进程，让NodeJS遭遇异常崩溃以后能马上复活。

另外，还应该把这些产生的异常记录到日志中，并让异常永远不再发生。

使用node来守护node

node-forever 提供了守护的功能和LOG日志记录功能。

安装非常容易

[sudo] npm install forever

使用也很简单

$ forever start simple-server.js
$ forever list
  [0] simple-server.js [ 24597, 24596 ]

还可以看日志

forever -o out.log -e err.log my-script.js

使用shell启动脚本守护node

使用node来守护的话资源开销可能会有点大，而且也会略显复杂，OurJS直接在开机启动脚本来进程线程守护。

如在debian中放置的 ourjs 开机启动文件： /etc/init.d/ourjs

这个文件非常简单，只有启动的选项，守护的核心功能是由一个无限循环 while true; 来实现的，为了防止过于密集的错误阻塞进程，每次错误后间隔1秒重启服务

WEB_DIR=＇/var/www/ourjs＇
WEB_APP=＇svr/ourjs.js＇

#location of node you want to use
NODE_EXE=/root/local/bin/node

while true; do
    {
        $NODE_EXE $WEB_DIR/$WEB_APP config.magazine.js
        echo "Stopped unexpected, restarting 

"
    } 2>> $WEB_DIR/error.log
    sleep 1
done

错误日志记录也非常简单，直接将此进程控制台当中的错误输出到error.log文件即可： 2>> $WEB_DIR/error.log 这一行, 2 代表 Error。

评论(0) 浏览(3278)

222020-3

"从客户端中检测到有潜在危险的 Request.Form 值"的解决方案汇总

seo达人

在一个asp.net 的项目中，前端通过ajax将富文本中的文字内容post到服务端的一个ashx中，在ashx中尝试读取参数值时，

结果报错：“从客户端中检测到有潜在危险的 Request.Form 值”

#事故分析
由于在asp.net中，Request提交时出现有html代码字符串时，程序系统会认为其具有潜在危险的值。会报出“从客户端中检测到有潜在危险的Request.Form值”这样的Error。

而富文本中的内容是包含html代码的，所以...

#解决方案：
1、前端对富文本字符串进行encodeURI编码，服务端进行HttpUtility.UrlDecode解码操作；
前端代码：

public void ProcessRequest(HttpContext context)
{
string str = context.Request["content"];
string content = HttpUtility.UrlDecode(str);
context.Response.ContentType = "text/plain";
context.Response.Write(content);
}
效果图：

2、前端不以form的方式提交，直接以json方式提交，服务端从request的body中读取数据，然后反序列化，得到信息；
前端代码：

string bodyText;
using (var bodyReader = new System.IO.StreamReader(context.Request.InputStream))
{
bodyText = bodyReader.ReadToEnd();
}
dynamic bodyObj = JsonConvert.DeserializeObject(bodyText);

context.Response.ContentType = "text/plain";
context.Response.Write(bodyObj.Content);
效果图：

#其他场景的解决方案：
1、aspx页面，当前页面进行form提交
打开当前.aspx页面，页头加上代码：validateRequest=”false”，如：

<%@ Page Language="C#" ValidateRequest="false" AutoEventWireup="false" CodeFile="default.aspx.cs" Inherits="default" %>
该方法不推荐，还有一种修改web.config配置文件的方法，强烈不推荐，就不写在这里了；

2、在ASP.NET MVC中的解决方案
1）、针对某个实体类的单个字段设置 [AllowHtml] ，这样提交的时候，系统就会放过该字段。

2）、前端代码：

public class NewInfo
{
public string Title { get; set; }
[AllowHtml]
public string Content { get; set; }
}
#写在最后
该文只是浅显的总结一下，其中涉及的xss方面，没有详细考虑，欢迎指正！

评论(0) 浏览(2707)

首页

http的状态码（中英文）

常见的HTTP状态码

学渣代表HTML知识基础语法篇

SS之盒子模型与背景属性————每天一遍小知识

Swift 闭包简单使用

Vue中如何监控某个属性值的变化

你不知道的--save-dev和--save的区别

node 模块简述

NodeJS服务总是崩溃的解决办法

事实上呢？

怎么解决呢？

使用uncaughtException

使用 try/catch

集成到框架中

守护NodeJS进程和记录错误日志

使用node来守护node

使用shell启动脚本守护node

"从客户端中检测到有潜在危险的 Request.Form 值"的解决方案汇总

分类

日历

链接

个人资料

存档