HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或

Posted 2023-04-27

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或相关的知识，希望对你有一定的参考价值。

“/”应用程序中的服务器错误。
--------------------------------------------------------------------------------

无法找到资源。
说明: HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或其名称已更改，或暂时不可用。请检查以下 URL 并确保其拼写正确。

请求的 URL: /assist/ServerListDDT.aspx要怎么办，
我打开http://youxi.baidu.com/go.xhtml?id=108&next=enter
然后点击进入，就显示这样了。

你关机在开机打开这个网页试一试，一般是没有什么问题的，我都能正常打开，如果还不能正常打开，就可能你的ie破坏了，或者和系统文件有冲突，试一试，应该没有问题了。参考技术A 我也样知道弄诶我打开上面网站算弹弹堂啦了额神奇······ 参考技术B 1 参考技术C 原因

Web 服务器在无法检索到所请求的页时，返回“HTTP 404 - File not found”错误信息。

下面是导致此错误信息的一些常见原因： ? 所请求的文件已被重命名。

? 所请求的文件已被移动到其他位置并且/或者被删除。

? 所请求的文件由于维护、升级或其他未知原因而暂时不可用。

? 所请求的文件不存在。

? IIS 6.0：没有启用相应的 Web 服务扩展或 MIME 类型。

? 某个虚拟目录映射到另一个服务器上的驱动器的根目录。

解决方案

要解决此问题，请验证在浏览器的 URL 中请求的文件存在于 IIS 计算机上，而且位于正确的位置。

请使用 IIS Microsoft 管理控制台 (MMC) 管理单元确定所请求的文件在 IIS 计算机的文件系统中应处的位置。

如果网站使用虚拟目录 (VDIR)，这一点特别重要。VDIR 是这样一个目录：网站的主目录中没有包含它，但从客户端浏览器上看好像包含它一样。此虚拟目录必须被映射到驱动器上的子文件夹或按名称引用文件。

例如，假设导致 404 错误的 URL 是 http://Microsoft.Com/Test/File1.htm，而且 IIS 管理单元为 Microsoft.Com 网站显示该 URL，/Test/ 目录实际上是一个映射到 IIS 计算机上 c:\Information 位置的虚拟目录。这意味着您必须验证 File1.htm 文件位于 c:\Information 目录中（并且验证文件名的拼写正确）。

IIS6 动态内容：当没有启用 Web 扩展时，W3C 扩展日志文件中会记录一个 404.2 项。使用 IIS Microsoft 管理控制台 (MMC) 管理单元启用相应的 Web 扩展。默认 Web 扩展包括：ASP、ASP.net、服务器端包含、WebDAV 发布、FrontPage 服务器扩展、通用网关接口 (CGI)。必须添加自定义扩展并明确启用它。请参见 IIS 6.0 帮助文件以了解更多信息。

IIS6 静态内容：当某个扩展没有映射到 MIME 映射属性中的已知扩展时，W3C 扩展日志文件中将会记录一个 404.3 项。使用 IIS Microsoft 管理控制台 (MMC) 管理单元在 MIME 映射中配置相应的扩展。请参见 IIS 6.0 帮助文件以了解更多信息。

我就是因为把主目录设置成了硬盘G盘的根目录所以才出现的这个问题，后来把主目录地址改到下一级目录就好了~~ 参考技术D 我也一样，不知道这么弄诶，但我打开你上面的那个网站，就算弹弹堂的啦，就可以了额，神奇······本回答被提问者采纳

HTTP -- HTTP相关协议（TCP/IPDNSURI/URLHTTPS）HTTP请求响应过程HTTP报文分析（请求方法URL）HTTP标头

1. HTTP相关协议

在互联网中，任何协议都不会单独的完成信息交换，HTTP也一样。虽然HTTP属于应用层的协议，但是它仍然需要其他层次协议的配合完成信息的交换。

1.1 TCP/IP

TCP/IP我们一般称之为协议簇，即TCP/IP协议簇中不仅仅只有TCP协议和IP协议，它是一系列网络通信协议的统称。而其中最核心的两个协议就是TCP/IP协议，其他的还有UDP、ICMP、ARP等等，共同构成了一个复杂但有层次的协议栈。

TCP协议的全称是Transmission Control Protocol的缩写，意思是传输控制协议，HTP使用TCP作为通信协议，这是因为TCP是一种可靠的协议，而可靠能保证数据不丢失。

IP协议的全称是Internet Protocol 的缩写，它主要解决的是通信双方寻址的问题。IP协议使用IP地址来标识互联网上的每一台计算机，计算机网络中信息交换必须先要知道对方的IP地址。

1.2 DNS（域名系统）

你有没有想过为什么你可以通过键入 https://www.bilibili.com 就能够获取你想要的网站?我们上面说到，计算机网络中的每个端系统都有一个IP地址存在，而把IP地址转换为便于人类记忆的协议就是DNS协议。

DNS的全称是域名系统(Domain Name System，缩写:DNS)，它是将域名和P地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

1.3 URL / URI

URI的全称是(Uniform Resource ldentifier) ，中文名称是统一资源标识符，使用它就能够唯一地标记互联网上资源。

URL 的全称是(Uniform Resource Locator) ，中文名称是统一资源定位符，也就是我们俗称的网址，它实际上是 URI的一个子集。

URI不仅包括URL，还包括URN(统一资源名称)，它们之间的关系如下：

1.4 HTTPS

HTTP一般是明文传输，很容易被攻击者窃取重要信息，鉴于此，HTTPS应运而生。

HTTPS 的全称为(Hyper Text Transfer Protocol over SecureSocket Layer)，全称有点长，HTTPS是以安全为目标的HTTP通道，在HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS在HTTP的基础上增加了SSL层，也就是说HTTPS = HTTP + SSL。

2. HTTP 请求响应过程

假设访问的URL地址为http: //www.someSchool.edu/someDepartment/home.index ，当我们输入网址并点击回车时，浏览器内部会进行如下操作：

DNS服务器会首先进行域名的映射，找到访问www.someSchool.edu 所在的地址，然后HTTP客户端进程在80端口发起一个到服务器www.someSchool.edu` 的TCP连接(80端口是HTTP的默认端口)。在客户和服务器进程中都会有一个套接字与其相连。
HTTP客户端通过它的套接字向服务器发送一个HTTP请求报文。该报文中包含了路径someDepartment/home.index的资源。
HTTP服务器通过它的套接字接受该报文，进行请求的解析工作，并从其存储器中检索出对象 www.someSchool.edu/someDepartment/home.index，然后把检索出来的对象进行封装，封装到HTTP响应报文中，并通过套接字向客户进行发送。
HTTP服务器随即通知TCP断开TCP连接，实际上是需要等到客户接受完响应报文后才会断开TCP连接。
HTTP客户端接受完响应报文后，TCP连接会关闭。HTTP客户端从响应中提取出报文中是一个HTML响应文件，并检查该HTML文件，然后循环检查报文中其他内部对象。
检查完成后，HTTP客户端会把对应的资源通过显示器呈现给用户。

至此，输入网址再按下回车的全过程就结束了。上述过程描述的是一种简单的请求-响应全过程，真实的请求-响应情况可能要比上面描述的过程复杂很多。

3. HTTP 请求特征（无连接、无状态）

支持客户-服务器模式
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

3. HTTP报文分析

HTTP协议主要由三大部分组成:

起始行(start line)：描述请求或响应的基本信息
头部字段(header)：使用key-value 形式更详细地说明报文
消息正文(entity)︰实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

其中起始行和头部字段并成为请求头或者响应头，统称为Header ；消息正文也叫做实体，称为body 。HTTP 协议规定每次发送的报文必须要有Header，但是可以没有body，也就是说头信息是必须的，实体信息可以没有。而且在 header 和 body之间必须要有一个空行（CRLF)

假设访问的URL地址为http: //www.someSchool.edu/someDepartment/home.index ，我们来看看他的请求报文

每个报文的起始行都是由三个字段组成:方法、URL字段和HTTP版本字段。

3.1 HTTP请求方法

我们一般最常用的方法也就是GET方法和POST方法，下面是 HTTP1.0和HTTP1.1支持的方法清单。

GET 获取资源，GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。
POST 传输实体，虽然GET方法也可以传输主体信息，但是便于区分，我们一般不用GET传输实体信息，反而使用POST传输实体信息。
PUT 传输文件，PUT方法用来传输文件。就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。但是，鉴于HTP的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全性问题。因此一般的Web 网站不使用该方法。
HEAD 获得响应首部，HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。
DELETE 删除文件，DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。
OPTIONS 询问支持的方法，OPTIONS方法用来查询针对请求URI指定的资源支持的方法。
TRACE 追踪路径，TRACE 方法是让 Web服务器端将之前的请求通信环回给客户端的方法。
CONNECT 要求用隧道协议连接代理，CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL (Secure Sockets Layer，安全套接层)和TLS(Transport Layer Security，传输层安全)协议把通信内容加密后经网络隧道传输。

3.2 HTTP请求URL

HTTP协议使用URI定位互联网上的资源。正是因为URI的特定功能，在互联网上任意位置的资源都能访问到。URL带有请求对象的标识符。

比如http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

http://，协议：对于大部分Web资源，通常使用HTTP协议或其安全版本，HTTPS 协议。另外，浏览器也知道如何处理其他协议。例如, mailto:协议指示浏览器打开邮件客户端；ftp:协议指示浏览器处理文件传输。
www.example.com，域名：域名也代表管理该域名的机构。它指示了需要向网络上的哪一台主机发起请求。当然，也可以直接向主机的 IP地址发起请求。
:80，端口：两个主机之间要发起TCP 连接需要两个条件，主机＋端口。它表示用于访问Web服务器上资源的入口。如果访问的该Web服务器使用HTTP协议的标准端口(HTTP为80，HTTPS为443)授予对其资源的访问权限，则通常省略此部分。否则端口就是URL必须的部分。
/path/to/myfile.html，路径：Web服务器上资源的路径。以端口后面的第一个/开始，到?号之前结束，中间的每一个/都代表了层级关系。这个URL的请求资源是一个html页面。
?key1=value1&key2=value2，查询参数：提供给Web服务器的额外参数。如果是GET请求，一般带有请求URL参数，如果是POST请求，则不会在路径后面直接加参数。这些参数是用&符号分隔的键/值对列表。key1 = value1是第一对，key2 = value2是第二对参数。
#SomewhereInTheDocument，片段：资源本身的某一部分的一个锚点。锚点代表资源内的一种“书签”，它给予浏览器显示位于该"加书签"点的内容的指示。例如，在HTML文档上，浏览器将滚动到定义锚点的那个点上；在视频或音频文档上，浏览器将转到锚点代表的那个时间。#号后面的部分，也称为片段标识符，永远不会与请求一起发送到服务器。

4. HTTP标头

HTTP 1.1的标头主要分为四种，通用标头、实体标头、请求标头、响应标头。

4.1 通用标头

HTTP通用标头主要用于传达有关消息本身的信息，而不是它所携带的内容。它们提供─般信息并控制如何处理和处理消息。

常见的通用标头为：

4.1.1 Cache-Control（缓存控制）

缓存(Cache)是计算机领域里的一个重要概念，是优化系统性能的利器。不仅计算机中的CPU为了提高指令执行效率从而选择使用寄存器作为辅助，计算机网络同样存在缓存。

Cache-Control是通用标头的指令，它能够管理如何对HTTP的请求或者响应使用缓存。

计算机网络中是可以有第三者出现的，也就是缓存服务器，这个指令通过影响请求/响应中的缓存服务器从而达到控制缓存的目的；不仅有缓存服务器，还有浏览器内部缓存也会影响链路的缓存。

这个标头中可以出现许多单独的指令。下表提供了一个Cache-Control选项。

请注意，在一个Cache-Control标头中只能出现一个指令，但是在消息中可以出现多个这样的标头。

上面这个表格其实会有四种分类

可缓存性︰它们分别是no-cache 、no-store、private和 public
缓存有效性时间︰它们分别是max-age、s-maxage、max-stale、min-fresh
重新验证并重新加载︰它们分别是must-revalidate和proxy-revalidate
其他︰它们分别是 only-if-cached和no-transform

no-cache:

no-cache很容易和no-store 混淆，一般都会把no-cache 认为是不缓存，其实不是这样。

使用no-cache 指令是为了防止从缓存中返回过期的资源（每次拿到资源后都与服务器的资源进行匹配，如果一致则返回该资源），例如下图所示

Cache-Control: no-cache

no-store:

no-store才是真正意义上的不缓存，每次服务器接受到客户端的请求后，都会返回最新的资源给客户端。

Cache-Control: no-store

max-age:

max-age可以用在请求或者响应中，当客户端发送带有max-age 的指令时，缓存服务器会判断自己缓存时间的数值和 max-age 的大小（max-age 的值是相对于请求时间的）。

如果比 max-age 小，那么缓存有效，可以继续给客户端返回缓存的数据。
如果比 max-age 大，那么缓存服务器将不能返回给客户端缓存的数据。

如果max-age = 0，那么缓存服务器将会直接把请求转发到服务器。

Cache-Control: max-age = 0

must-revalidate:

表示一旦资源过期，缓存就必须在原始服务器上成功验证的情况下才使用其过期的数据。

Cache-Control: must-revalidate

no-store 、no_cache 、must-revalidate和max-age可以一起看，下面是一个这四个标头的流程图

public / private:

public属性只出现在客户端响应中，表示响应可以被任何缓存所缓存。在计算机网络中，分为两种缓存，共享缓存（public）和私有缓存（private），如下所示：

Cache-Control: public

当指定private指令后，响应只以特定的用户作为对象，这与public 的用法相反，缓存服务器只对特定的客户端进行缓存，其他客户端发送过来的请求，缓存服务器则不会返回缓存。

Cache-Control: private

4.1.2 Connection（持久性连接/非持久性连接）

HTTP协议使用TCP来管理连接方式，主要有两种连接方式，持久性连接和非持久性连接。

持久性连接：

持久性连接指的是一次会话完成后，TCP连接并未关闭，第二次再次发送请求后，就不再需要建立TCP连接，而是可以直接进行请求和响应。它的一般表示形式如下

Connection: keep-alive

从HTTP 1.1开始，默认使用持久性连接。
keep-alive也是一个通用标头，一般Connection都会和keep-alive 一起使用，keep-alive 有两个参数，一个是timeout；另一个是max，它们的主要表现形式如下：

Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000

timeout：指的是空闲连接必须打开的最短时间，也就是说这次请求的连接时间不能少于5秒
max：指的是在连接关闭之前服务器所能够收到的最大请求数。

非持久性连接：

非持久性连接表示一次会话请求/响应后关闭连接的方式。HTTP 1.1之前使用的连接都是非持久连接。

Connection: close

4.1.3 Date

Date是一个通用标头，它可以出现在请求标头和响应标头中，它的基本表示如下：

// 表示的是格林威治标准时间，这个时间要比北京时间慢八个小时
Date: Wed, 21 0ct 2015 07:28:00 GMT

4.1.4 Pragma

Pragma是 http 1.1之前版本的历史遗留字段，仅作为与http的向后兼容而定义。它的一般形式如下：

Pragma: no-cache

只用于客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。

如果所有的中间服务器都以实现 HTTP/1.1为标准，那么直接使用Cache-Control: no-cache即可，如果不是的话，就要包含两个字段，如下：

Cache-Control: no-cache
Pragma: no-cache

4.1.5 Trailer

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。该首部字段可应用在HTTP/1.1版本分块传输编码时。一般用法如下：

Transfer-Encoding: chunked
Trailer: Expires

以上用例中，指定首部字段Trailer 的值为Expires，在报文主体之后（分块长度0之后)出现了首部字段Expires。

4.1.6 Transfer-Encoding

Transfer-Encoding规定了传输报文所采用的编码方式

注意：HTTP1.1的传输编码方式仅对分块传输有效，但是 HTTP 2.0就不再支持分块传输，而提供了自己更有效的数据传输机制。

Transfer-Encoding: chunked

HTTP报文标头除了可以根据属性所在的位置分为通用标头、请求标头、响应标头和实体标头；还可以按照是否被缓存分为端到端首部(End-to-End)和逐跳首部(Top-to-Top)。Transfer-Encoding 属于Hop-by-hop(逐跳)首部。

除了下面八种属于逐跳首部外，其余都属于端到端首部：

Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE（告知服务器客户端能够处理响应的传输编码方式及相对优先级）
Transfer-Encoding
Upgrade

Transfer-Encoding用于两个节点之间传输消息，而不是资源本身。在多个节点传输消息的过程中，每一段消息的传输都可以使用不同的Transfer-Encoding。如图所示：

Transfer-Encoding支持文件压缩，如果你想要以文件压缩后的形式发送的话。Transfer-Encoding 所有可选类型如下：

chunked ︰数据按照一系列块发送，在这种情况下，将省略Content-Length标头，并在每个块的开头，需要以十六进制填充当前块的长度，后跟\\r\\n，然后是块本身，然后是另一个\\r\\n。当将大量数据发送到客户端并且在请求已被完全处理之前，可能无法知道响应的总大小时，分块编码很有用。例如，在生成由数据库查询产生的大型HTML表时或在传输大型图像时。终止块通常是0，紧随Transfer-Encoding后面的是Trailer标头， Trailer可能为空。分块的响应看起来像这样：
compress：使用Lempel-Ziv-Welch(LZW)算法的格式。
deflate：使用zlib(在RFC 1950定义)结构和deflate压缩算法。
gzip：使用Lempel-Ziv编码(LZ77)和32位CRC的格式。这最初是UNIX gzip程序的格式。HTTP / 1.1标准还建议出于兼容性目的，支持此内容编码的服务器应将x-gzip识别为别名。
identity :使用身份功能（即无压缩或修改)。

也可以列出多个值，以逗号分隔，类似一个集合列表：

Transfer-Encoding: gzip, chunked

4.1.7 Upgrade

首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

上图用例中，首部字段Upgrade指定的值为TLS/1.0。请注意此处两个字段首部字段的对应关系，Connection的值被指定为Upgrade。Upgrade首部字段产生作用的对象仅限于客户端和临近服务器之间。因此，使用首部字段Upgrade时，还需要额外指定Connection: Upgrade。对于附有首部字段Upgrade 的请求，服务器可用101 Switching Protocols状态码作为响应返回。

4.1.8 Via

使用Via是为了跟踪客户端和服务器之间的请求/响应路径

Via后面的的 1.1，1.0表示接收服务器上的HTTP版本，Via首部是为了跟踪路径，经常和TRACE 方法一起使用。

4.1.9 Warning

Warning通用HTTP标头通常会告知用户一些与缓存相关的问题的警告。HTTP/1.1中定义了7种警告。

4.2 请求标头

请求标头用于客户端发送HTTP请求到服务器中所使用的字段，下面是HTTP请求标头常见字段:

4.2.1 Accept（客户端能够接收的MIME类型）

HTTP请求标头会告知客户端能够接收的MIME类型是什么
MIME: MIME (Multipurpose Internet Mail Extensions)是描述消息内容类型的因特网标准。MIME消息能包含文本、图像、音频、视频以及其他应用程序专用的数据。

MIME类型其实就是一系列消息内容类型的集合。那么MIME类型都有哪些呢？

文本文件：text/html、text/plain、text/css、application/xhtml+xml、application/xml
图片文件：image/jpeg、image/gif、image/png
视频文件：video/mpeg、video/quicktime
应用程序二进制文件：application/octet-stream、application/zip

比如，如果浏览器不支持 PNG 图片的显示，那Accept 就不指定image/png，而指定可处理的image/gif 和 image/jpeg 等图片类型。

一般MIME类型也会和q这个属性一起使用，q是什么? q表示的是权重，来看一个例子。

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

这是什么意思呢?若想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值，没有显示权重的时候默认值是1.0。

也就是说，这是一个放置顺序，权重高的在前，低的在后，application/xml;q=0.9是不可分割的整体。

4.2.2 Accept-Charset（客户端能够接受的字符编码）

Accept-Charset表示客户端能够接受的字符编码。Accept-Charset也是属于内容协商的一部分，它和Accept一样，也可以用q来表示字符集，用逗号进行分割，例如：

Accept-Charset: iso-8859-1
Accept-Charset: utf-8, iso-8859-1;q=0.5
Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1

很多以Accept-*开头的标头，都是属于内容协商的范畴。

4.2.3 Accept-Encoding（客户端希望服务端返回的内容编码）

表示HTTP标头会标明客户端希望服务端返回的内容编码，这通常是一种压缩算法。Accept-Encoding也是属于内容协商的一部分，使用并通过客户端选择Content-Encoding内容进行返回。

下面是Accept-Encoding的使用方式：

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

上面的几种表述方式就已经把 Accept-Encoding的属性列全了

gzip：由文件压缩程序 gzip 生成的编码格式。
compress ：使用Lempel-Ziv-Welch (LZW)算法的压缩格式
deflate：使用zlib 结构和deflate压缩算法的压缩格式
br：使用Brotli算法的压缩格式
identity :使用身份功能（即无压缩或修改)。
*：匹配标头中未列出的任何内容编码，如果没有列出Accept-Encoding ，这就是默认值，并不意味着支持任何算法，只是表示没有偏好。
;q=采用权重q值来表示相对优先级，这点与首部字段Accept相同。

4.2.4 Accept-Language

Accept-Language请求表示客户端需要服务端返回的语言类型，Accept-Language 也属于内容协商的范畴。服务端通过Content-Language进行响应，和Accept首部字段一样，按权重值q来表示相对优先级。例如：

Accept-Language: de
Accept-Language: de-CH
Accept-Language: en-US,en;q=0.5

4.2.5 Authorization

Authorization请求标头用于向服务器认证用户代理的凭据。

请求标头Authorization是用来告知服务器，用户的认证信息，服务器在只有收到认证后才会返回给客户端200 OK的响应，如果没有认证信息，则会返回401并告知客户端需要认证信息。

4.2.6 Expect

Expect HTTP 请求标头指示服务器需要满足的期望才能正确处理请求。如果服务器没有办法完成客服端所期望完成的事情并且服务端存在错误的话，会返回417 Expectation Failed 。HTTP 1.1只规定了100-continue 。

如果服务器能正常完成客户端所期望的事情，会返回100
如果不能满足期望或返回任何其他4xx的状态码，会返回417

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

4.2.7 From

From请求头用来告知服务器使用用户代理的电子邮件地址。通常情况下，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。我们在使用代理的情况下，应尽可能包含From首部字段。例如：

From: webmaster@example.org

4.2.8 Host

Host请求头指明了服务器的域名(对于虚拟主机来说)，以及（可选的)服务器监听的TCP端口号。如果没有给定端口号，会自动使用被请求服务的默认端口（比如请求一个HTTP的URL会自动使用8O作为端口，HTTPS默认请求端口为443)。

Host: www.bilibili.com

Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。

4.2.9 If-Match

lf-Match后面可以跟一大堆属性，形式像lf-Match这种的请求头称为条件请求，服务器接收到条件请求后，需要判定条件请求是否满足，只有条件请求为真，才会执行条件请求。

类似的还有

lf-Match
lf-Modified-Since
lf-None-Match
lf-Range
lf-Unmodified-Since

服务器会比对If-Match的字段值和资源的ETag值，仅当两者一致时，才会执行请求。
反之，则返回状态码412 Precondition Failed的响应。还可以使用星号（*）指定If-Match的字段值。针对这种情况，服务器将会忽略ETag的值，只要资源存在就处理请求。

4.2.10 lf-Modified-Since

If-Modified-Since是 HTTP条件请求的一部分，只有在给定日期之后，服务端修改了请求所需要的资源，才会返回200 OK的响应。如果在给定日期之后，服务端没有修改内容，响应会返回304并且不带任何响应体。lf-Modified-Since 只能使用GET和HEAD 请求。

lf-Modified-Since与 lf-None-Match结合使用时，它将被忽略，除非服务器不支持 lf-None-Match。一般表示如下：

If-Modified-Since: Thu，15 Apr 2004 00:00:00 GMT

4.2.11 lf-None-Match

只有在If-None-Match的字段值与ETag值不一致时，可处理该请求。与If-Match首部字段的作用相反

4.2.12 If-Range

If-Range也是条件请求，如果满足条件(lf-Range的值和 ETag值或者更新的日期时间一致)，则会发出范围请求，否则将会返回全部资源。它的一般表示如下：

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

4.2.13 If-Unmodified-Since

If-Unmodified-Since HTP请求标头也是一个条件请求，服务器只有在给定日期之后没有对其进行修改时，服务器才返回请求资源。如果在指定日期时间后发生了更新，则以状态码 412（Precondition Failed）作为响应返回。

4.2.14 Max-Forwards

通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，会将Max-Forwards的值减1后重新赋值。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。

4.2.15 Proxy-Authorization

Proxy-Authorization是属于请求与认证的范畴，我们在上面提到一个认证的HTTP标头是Authorization，不同于Authorization发生在客户端–服务器之间；Proxy-Authorization发生在代理服务器和客户端之间。它表示接收到从代理服务器发来的认证时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。

4.2.16 Range

Range: bytes=5001-10000

对于只需获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围。上面的示例表示请求获取从第5001字节至第10000字节的资源。

接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206Partial Content的响应。无法处理该范围请求时，则会返回状态码200 OK的响应及全部资源。

4.2.17 Referer

首部字段Referer会告知服务器请求的原始资源的URI。

4.2.18 TE

TE:gzip, deflate; g=0.5

首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相对优先级。它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。

首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分块传输编码的方式。应用后者时，只需把trailers赋值给该字段值。

TE:trailers

4.2.19 User-Agent

首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

4.3 响应标头

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

4.3.1 Accept-Ranges

Accept-Ranges HTTP响应标头，这个标头有两个值：

当服务器能够处理客户端发送过来的请求时，使用bytes 来指定
当服务器不能处理客户端发来的请求时，使用none来指定

Accept-Ranges: bytes
Accept-Ranges: none

4.3.2 Age

首部字段Age能告知客户端，源服务器在多久前创建了响应。

字段值的单位为秒。若创建该响应的服务器是缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。

4.3.3 ETag

ETag对于条件请求来说真是太重要了。因为条件请求就是根据ETag 的值进行匹配的。

ETag响应头是特定版本的标识，它能够使缓存变得更高效并能够节省带宽，因为如果缓存内容未发生变更，Web服务器则不需要重新发送完整的响应。除此之外，ETag能够防止资源同时更新互相覆盖。

如果给定URL上的资源发生变更，必须生成一个新的ETag值，通过比较它们可以确定资源的两个表示形式是否相同。

ETag值有两种，一种是强ETag，一种是弱ETag：

强ETag值，无论实体发生多么细微的变化都会改变其值，一般的表示如下

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

弱ETag值，弱ETag值只用于提示资源是否相同。只有资源发生了根本改变，产生差异时才会改变ETag 值。这时，会在字段值最开始处附加W/。

ETag: W/"0815"

4.3.4 Location

使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。

基本上，该字段会配合3xx:Redirection的响应，提供重定向的URI。

几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。

4.3.5 Proxy-Authenticate

HTTP响应标头Proxy-Authenticate会定义认证方法，应该使用身份验证方法来访问代理服务器后面的资源即客户端。

它与HTTP客户端和服务端之间的访问认证行为相似，不同之处在于Proxy-Authenticate的认证双方是客户端与代理之间。它的一般表示形式如下：

Proxy-Authenticate: Basic
Proxy-Authenticate: Basic realm="Access to the internal site"

4.3.6 Retry-After

HTTP响应标头Retry-After告知客户端需要在多久之后重新发送请求。

字段值可以指定为具体的日期时间（Wed， 04 Jul 2012 06:34:24 GMT），也可以是创建响应后的秒数。

4.3.7 Server

服务器标头包含有关原始服务器用来处理请求的软件的信息。例如：

Server: Apache/2.4.1 (Unix)

4.3.8 Vary

当代理服务器接收到带有Vary首部字段指定获取资源的请求时，如果使用的Accept-Language字段的值相同，那么就直接从缓存返回响应。反之，则需要先从源服务器端获取资源后才能作为响应返回。

4.3.9 www-Authenticate

首部字段WWW-Authenticate用于HTTP访问认证。它会告知客户端适用于访问请求URI所指定资源的认证方案（Basic或是Digest）和带参数提示的质询（challenge）。状态码401 Unauthorized响应中，肯定带有首部字段WWW-Authenticate。它的一般表示形式如下：

WWW-Authenticate: Basic
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"

4.4 实体标头

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

4.4.1 Allow

首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时，会以状态码405 Method Not Allowed作为响应返回。与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。

4.4.2 Content-Encoding

我们上面讲过Accept-Encoding是客户端希望服务端返回的内容编码，但是实际上服务端返回给客户端的内容编码实际上是通过Content-Encoding返回的。内容编码是指在不丢失实体信息的前提下所进行的压缩。主要也是四种，和Accept-Encoding 相同，它们是 gzip、compress、deflate、identity。下面是一组请求/响应内容压缩编码：

Accept-Encoding: gzip, deflate
Content-Encoding: gzip

4.4.3 Content-Language

首部字段Content-Language 会告知客户端，服务器使用的自然语言是什么，它与 Accept-Language相对，下面是一组请求/响应使用的语言类型：

Content-Language: zh-CN

4.4.4 Content-Length

Content-Length 的实体标头指服务器发送给客户端的实际主体大小，以字节为单位。

如下，服务器返回给客户端的主体大小是2022字节。

Content-Length: 2022

4.4.5 Content-Location

Location 和Content-Location是不一样的，Location表示重定向的URL，而 Content-Location表示用于访问资源的直接URL，以后无需进行进一步的内容协商。Location是与响应关联的标头，而Content-Location是与返回的数据相关联的标头。

4.4.6 Content-MD5

首部字段Content-MD5是一串由MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。

客户端会对接收的报文主体执行相同的MD5算法，然后与首部字段Content-MD5的字段值比较。

4.4.7 Content-Range

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位，表示当前发送部分及整个实体大小。

4.4.8 Content-Type

HTTP响应标头Content-Type说明了实体内对象的媒体类型，和首部字段Accept一样使用表示服务器能够响应的媒体类型。

Content-Type: text/ html; charset=UTF一8

4.4.9 Expires

首部字段Expires会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

当首部字段Cache-Control有指定max-age指令时，比起首部字段Expires，会优先处理max-age指令。

4.4.10 Last-Modified

首部字段Last-Modified指明资源最近一次修改的时间。

以上是关于HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或的主要内容，如果未能解决你的问题，请参考以下文章

无法找到资源。说明: HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或其名称已更改，

说明: HTTP 404。您正在查找的资源(或者它的一个依赖项)可能已被移除，或其名称已更改【怎么解决呢？】

MVC 3.0错误 HTTP 404您正在查找的资源(或者它的一个依赖项)可能已被移除，或其名称已更改，或暂时不可用。请检查以下 URL 并确保其拼写正确。

C# mvc 同样的程序包发布，iis多台webservice可以访问，一台webservice出现问题

\.net发布前调试没问题可发布后找不到url

ASP.NET MVC：404 - 找不到文件或目录。您正在寻找的资源