西安网站制作机构h5网站建设模板下载

当前位置： 首页 > news >正文

西安网站制作机构,h5网站建设模板下载,wordpress扒主题,昆明pc网站建设HTTP 报文格式 HTTP 协议的请求报文和响应报文的结构基本相同#xff0c;由四部分组成#xff1a; ① 起始行#xff08;start line#xff09;#xff1a;描述请求或响应的基本信息#xff1b;② 头部字段集合#xff08;header#xff09;#xff1a;使用 key-valu… HTTP 报文格式 HTTP 协议的请求报文和响应报文的结构基本相同由四部分组成 ① 起始行start line描述请求或响应的基本信息② 头部字段集合header使用 key-value 形式更详细地说明报文③ 空行 CRLF回车换行④ 消息正文body实际传输的数据它不一定是纯文本可以是图片、视频等二进制数据。 HTTP 是一个 “纯文本” 的协议所以头数据都是 ASCII 码的文本可以很容易地用肉眼阅读。 请求报文格式 响应报文格式 请求报文的请求行 请求行简要地描述了客户端想要如何操作服务器端的资源。 请求行由三部分组成请求方法 空格 URI 空格 版本号 CRLF回车换行 ① 请求方法是一个动词如 GETPOST表示对资源的操作方式② 请求目标请求目标的路径 path通常是一个 URI标记了请求方法要操作的资源③ 版本号表示报文使用的 HTTP 协议版本如 HTTP/1.1 。 这三个部分通常使用空格space来分隔 URI统一资源标识符Uniform Resource Identifier 响应报文的状态行 在这里它不叫“响应行”而是叫“状态行”status line意思是服务器响应的状态。 状态行由三部分组成版本号 空格 状态码 空格 原因 CRLF回车换行 ① 版本号表示报文使用的 HTTP 协议版本如 HTTP/1.1② 状态码一个 3 位数字表示处理的结果比如 200-成功500-服务器错误404-资源不存在③ 原因描述作为数字状态码补充是更详细的解释文字帮助人理解原因。 头部字段 HTTP协议规定了非常多的头部字段实现各种各样的功能但基本上可以分为四大类 ① 通用字段在请求头和响应头里都可以出现比如 Date、Connection ② 请求字段仅能出现在请求头里进一步说明请求信息或者额外的附加条件比如 Host、Accept 等 ③ 响应字段仅能出现在响应头里补充说明响应报文的信息比如 Server 等 ④ 实体字段它实际上属于通用字段但专门描述 body 的额外信息。比如 Content-Length 等
对 HTTP 报文的解析和处理实际上主要就是对头字段的处理理解了头字段也就理解了 HTTP 报文。 常用头字段 - Host 字段 Host 是一个请求字段只能出现在请求头里。 Host 同时也是唯一一个 HTTP/1.1 规范里要求必须出现的字段也就是说如果请求头里没有 Host那这就是一个错误的报文。 Host 字段其实是在告诉服务器这个请求应该由哪个主机来处理。
常用头字段 - User-Agent 字段 User-Agent 是一个请求字段只出现在请求头里。 它使用一个字符串来描述发起 HTTP 请求的客户端服务器可以依据它来返回最合适此浏览器显示的页面。
常用头字段 - Date 字段 Date 字段是一个通用字段但通常出现在响应头里表示 HTTP 报文创建的时间客户端可以使用这个时间再搭配其他字段决定缓存策略。 常用头字段 - Server 字段 Server 字段是一个响应字段只能出现在响应头里。 它告诉客户端当前正在提供 Web 服务的软件名称 和 版本号。 Server 字段也不是必须要出现的因为这会把服务器的一部分信息暴露给外界如果这个版本恰好存在bug那么黑客就有可能利用 bug 攻陷服务器。所以有的网站响应头里要么没有这个字段要么就给出一个完全无关的描述信息。
常用头字段 - Content-Length 字段 实体字段里要说的一个是 Content-Length它表示报文里 body 的长度也就是请求头或响应头空行后面数据的长度。 服务器看到这个字段就知道了后续有多少数据可以直接接收。如果没有这个字段那么 body 就是不定长的需要使用 chunked 方式分段传输。
body 相关的头部字段 Accept: 表示客户端可解析的数据类型可以用逗号分隔列出多个类型 Accept-Encoding: 表示客户端支持的压缩格式可省略不压缩 Accept-Language: 客户端支持的语言 Accept-Charset: 通常不发送浏览器都支持多种字符集 Content-Type: 响应实体的真实类型可以出现在请求头和响应头中 Content-Encoding: 服务端告诉客户端响应实体使用了哪种压缩算法可省略不压缩 Content-Language: 服务端通常不发送表示使用的语言一般可以由 Content-Type 中的字符集推断出来如 Content-Type:text/html; charsetutf-8 Transfer-Encoding: chunked表示分块传输每个块包含两部分长度头和数据块最后一个块长度为 0 表示结束即0\r\n\r\n Transfer-Encoding: chunked 和 Content-Length 两个字段是互斥的响应报文中这两个字段不能同时出现。
body 数据类型 HTTP 常用的四类数据包括text、image、audio/video、application 每个大类下再细分出多个子类形式是“typesubtype”的字符串 ① text: 文本格式的可读数据如 text/html超文本text/plain纯文本text/css样式表等 ② image: 图像文件如 image/gif、image/jpeg、image/png等 ③ audio/video: 音频和视频数据如audio/mpeg、video/mp4等 ⑤ application格式不固定可以是文本或二进制必须由上层应用来解释常见的有 application/json、application/javascript、application/pdf等 如果不知道数据是什么类型就用 application/octet-stream 即不透明的二进制数据
body 数据压缩 压缩算法 ① gzip: GUN zip 压缩格式互联网上最流行的压缩算法② deflatezlib 压缩格式③ br: 一种专门为 http 优化的新压缩算法 压缩对应的头部字段 Accept 字段标记的是客户端可解析的数据类型可以用,做分隔符列出多个类型让服务器有更多的选择余地 上图中的 Accept 字段含义是在告诉服务器“我能够看懂 HTML、json 的文本还有 webp 和 png的图片请给我这四类格式的数据” Accept-Encoding 字段标记的是客户端支持的压缩格式 Content-Encoding服务器可以选择 Accept-Encoding 字段描述的压缩格式的其中一种来压缩数据实际使用的压缩格式放在响应头的 Content-Encoding 字段里
Accept-Encoding 和 Content-Encoding 都可以省略即不压缩。 body 语言类型字符集编码 对应的头字段 不过现在的浏览器都支持多种字符集通常不会发送 Accept-Charset而服务器也不会发送 Content-Language因为使用的语言完全可以由字符集推断出来所以请求头里一般只会有 Accept-Language 字段响应头里只会有 Content-Type 字段。 body 内容协商的质量值 在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候还可以用一种特殊的 “q” 参数表示权重来设定优先级这里的 “q” 是 “quality factor” 的意思。 权重的最大值是 1最小值是0.01默认值是1如果值是0就表示拒绝。具体的形式是在数据类型或语言代码后面加一个 “;”然后后面跟上 “qvalue”。 它表示浏览器最希望使用的是 html 文件权重是1其次是xml文件权重是0.9最后是任意数据类型*/*权重是0.8。 服务器收到请求头后就会计算权重再根据自己的实际情况优先输出 HTML 或者 XML。 分块传输 “Transfer-Encoding: chunked” 意思是报文里的 body 部分不是一次性发过来的而是分成了许多的块chunk逐个发送。 注意“Transfer-Encoding: chunked” 和 “Content-Length” 两个字段是互斥的响应报文中这两个字段不能同时出现因为一个响应报文的长度要么是已知的要么是未知的chunked。 按范围取数据 Accept-Range: bytes 响应报文中出现表示服务器支持按字节来取范围数据Range: bytesstart-end 请求报文中出现表示要取哪段数据Content-Range:start-end/total 响应报文中出现表示发送的是哪段数据 主要用途断点续传、多线程下载。 HTTP 请求方法 目前 HTTP/1.1 规定了八种请求方法单词都必须是大写的形式 ① GET获取资源可以理解为读取或者下载数据② HEAD获取资源的元信息③ POST向资源提交数据相当于写入或上传数据④ PUT类似 POST⑤ DELETE删除资源⑥ CONNECT建立特殊的连接隧道⑦ OPTIONS列出可对资源实行的方法⑧ TRACE追踪请求 — 响应的传输路径。 GET 和 HEAD GET 的含义是请求从服务器获取资源这个资源既可以是静态的文本、页面、图片、视频也可以是由 PHP、Java 动态生成的页面或者其他格式的数据。 HEAD 方法与 GET方法类似也是请求从服务器获取资源服务器的处理机制也是一样的但服务器不会返回请求的实体数据只会传回响应头也就是资源的“元信息”。
比如想要检查一个文件是否存在只要发个 HEAD 请求就可以了没有必要用 GET 把整个文件都取下来。再比如要检查文件是否有最新版本同样也应该用 HEAD服务器会在响应头里把文件的修改时间传回来。 POST 和 PUT POST 也是一个经常用到的请求方法使用频率应该是仅次于 GET应用的场景也非常多只要向服务器发送数据用的大多数都是 POST。 PUT 的作用与 POST 类似也可以向服务器提交数据但与 POST 存在微妙的不同通常 POST 表示的是“新建”“create”的含义而 PUT 则是“修改”“update”的含义。
在实际应用中PUT 用到的比较少。而且因为它与 POST 的语义、功能太过近似有的服务器甚至就直接禁止使用 PUT 方法只用 POST 方法上传数据。 响应状态码 目前 RFC 标准里规定的状态码是三位数所以取值范围就是[000~999] RFC 标准把状态码分成了五类用数字的第一位表示分类而0~99不用这样状态码的实际可用范围就大大缩小了由 [000~999] 变成了 [100~599]。 这五类的具体含义是 1xx提示信息表示目前是协议处理的中间状态还需要后续的操作2xx成功报文已经收到并被正确处理3xx重定向资源位置发生变动需要客户端重新发送请求4xx客户端错误请求报文有误服务器无法处理5xx服务器错误服务器在处理请求时内部发生了错误。 状态码详表 状态码状态信息含义100Continue初始的请求已经接受客户应当继续发送请求的其余部分。HTTP 1.1新101Switching Protocols服务器将遵从客户的请求转换到另外一种协议HTTP 1.1新102Processing由WebDAVRFC 2518扩展的状态码代表处理将被继续执行。200OK一切正常对GET和POST请求的应答文档跟在后面。201Created服务器已经创建了文档Location头给出了它的URL。202Accepted已经接受请求但处理尚未完成。203Non-Authoritative Information文档已经正常地返回但一些应答头可能不正确因为使用的是文档的拷贝HTTP 1.1新。204No Content没有新文档浏览器应该继续显示原来的文档。如果用户定期地刷新页面而Servlet可以确定用户文档足够新这个状态代码是很有用的。205Reset Content没有新的内容但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容HTTP 1.1新。206Partial Content客户发送了一个带有Range头的GET请求服务器完成了它HTTP 1.1新。207Multi-Status由WebDAV(RFC 2518)扩展的状态码代表之后的消息体将是一个XML消息并且可能依照之前子请求数量的不同包含一系列独立的响应代码。300Multiple Choices客户请求的文档可以在多个位置找到这些位置已经在返回的文档内列出。如果服务器要提出优先选择则应该在Location应答头指明。301Moved Permanently客户请求的文档在其他地方新的URL在Location头中给出浏览器应该自动地访问新的URL。302Found类似于301但新的URL应该被视为临时性的替代而不是永久性的。注意在HTTP1.0中对应的状态信息是“Moved Temporatily”。出现该状态代码时浏览器能够自动访问新的URL因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使用。例如如果浏览器错误地请求http://host/~user缺少了后面的斜杠有的服务器返回301有的则返回302。严格地说我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见307。303See Other类似于301/302不同之处在于如果原来的请求是POSTLocation头指定的重定向目标文档应该通过GET提取HTTP 1.1新。304Not Modified客户端有缓冲的文档并发出了一个条件性的请求一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档。服务器告诉客户原来缓冲的文档还可以继续使用。305Use Proxy客户请求的文档应该通过Location头所指明的代理服务器提取HTTP 1.1新。306Switch Proxy在最新版的规范中306状态码已经不再被使用。307Temporary Redirect和 302Found相同。许多浏览器会错误地响应302应答进行重定向即使原来的请求是POST即使它实际上只能在POST请求的应答是303时才 能重定向。由于这个原因HTTP 1.1新增了307以便更加清除地区分几个状态代码当出现303应答时浏览器可以跟随重定向的GET和POST请求如果是307应答则浏览器只 能跟随对GET请求的重定向。HTTP 1.1新400Bad Request请求出现语法错误。401Unauthorized客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头浏览器据此显示用户名字/密码对话框然后在填写合适的Authorization头后再次发出请求。402Payment Required该状态码是为了将来可能的需求而预留的。403Forbidden资源不可用。服务器理解客户的请求但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。404Not Found无法找到指定位置的资源。这也是一个常用的应答。405Method Not Allowed请求方法GET、POST、HEAD、DELETE、PUT、TRACE等对指定的资源不适用。HTTP 1.1新406Not Acceptable指定的资源已经找到但它的MIME类型和客户在Accpet头中所指定的不兼容HTTP 1.1新。407Proxy Authentication Required类似于401表示客户必须先经过代理服务器的授权。HTTP 1.1新408Request Timeout在服务器许可的等待时间内客户一直没有发出任何请求。客户可以在以后重复同一请求。HTTP 1.1新409Conflict通常和PUT请求有关。由于请求和资源的当前状态相冲突因此请求不能成功。HTTP 1.1新410Gone所请求的文档已经不再可用而且服务器不知道应该重定向到哪一个地址。它和404的不同在于返回407表示文档永久地离开了指定的位置而404表示由于未知的原因文档不可用。HTTP 1.1新411Length Required服务器不能处理请求除非客户发送一个Content-Length头。HTTP 1.1新412Precondition Failed请求头中指定的一些前提条件失败HTTP 1.1新。413Request Entity Too Large目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求则应该提供一个Retry-After头HTTP 1.1新。414Request URI Too LongURI太长HTTP 1.1新。415Unsupported Media Type对于当前请求的方法和所请求的资源请求中提交的实体并不是服务器中所支持的格式因此请求被拒绝。416Requested Range Not Satisfiable服务器不能满足客户在请求中指定的Range头。HTTP 1.1新417Expectation Failed在请求头 Expect 中指定的预期内容无法被服务器满足或者这个服务器是一个代理服务器它有明显的证据证明在当前路由的下一个节点上Expect 的内容无法被满足。421There are too many connections from your internet address从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常这里的IP地址指的是从服务器上看到的客户端地址比如用户的网关 或者代理服务器地址。在这种情况下连接数的计算可能涉及到不止一个终端用户。422Unprocessable Entity请求格式正确但是由于含有语义错误无法响应。RFC 4918 WebDAV423Locked当前资源被锁定。RFC 4918 WebDAV424Failed Dependency由于之前的某个请求发生的错误导致当前请求失败例如 PROPPATCH。RFC 4918 WebDAV425Unordered Collection在WebDav Advanced Collections 草案中定义但是未出现在《WebDAV 顺序集协议》RFC 3658中。426Upgrade Required客户端应当切换到TLS/1.0。RFC 2817449Retry With由微软扩展代表请求应当在执行完适当的操作后进行重试。500Internal Server Error服务器遇到了意料不到的情况不能完成客户的请求。501Not Implemented服务器不支持实现请求所需要的功能。例如客户发出了一个服务器不支持的PUT请求。502Bad Gateway服务器作为网关或者代理时为了完成请求访问下一个服务器但该服务器返回了非法的应答。503Service Unavailable服务器由于维护或者负载过重未能应答。例如Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。504Gateway Timeout由作为代理或网关的服务器使用表示不能及时地从远程服务器获得应答。HTTP 1.1新505HTTP Version Not Supported服务器不支持请求中所指明的HTTP版本。HTTP 1.1新506Variant Also Negotiates由《透明内容协商协议》RFC 2295扩展代表服务器存在内部配置错误被请求的协商变元资源被配置为在透明内容协商中使用自己因此在一个协商处理中不是一个合适的重点。507Insufficient Storage服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)509Bandwidth Limit Exceeded服务器达到带宽限制。这不是一个官方的状态码但是仍被广泛使用。510Not Extended获取资源所需要的策略并没有没满足。RFC 2774 HTTP 重定向 当一个客户端访问某个 URL 的时候由于某种原因服务端会告诉客户端需要重新访问另一个 URL这就是重定向。 最常见的重定向状态码就是301和302301俗称“永久重定向”Moved Permanently 302 俗称“临时重定向”“Moved Temporarily” 。 “Location” 字段属于响应字段必须出现在响应报文里。但只有配合 ³⁰¹⁄₃₀₂ 状态码才有意义它标记了服务器要求重定向的 URL。 301 永久重定向 很多客户端记住的是原 URL但是这个 URL在服务端已经不用了此时请求服务器会返回 301浏览器看到 301就知道原来的 URL “过时”了就会做适当的优化。比如刷新历史记录、更新书签下次可能就会直接用新的 URL 访问省去了再次跳转的成本。 302 临时重定向 302 俗称“临时重定向”“Moved Temporarily”意思是原 URL 处于“临时 维护”状态新的 URL是起“顶包”作用的“临时工”。 浏览器看到 302会认为原来的 URL 仍然有效但暂时不可用所以只会执行简单的跳转页面不记录新的 URL也不会有其他的多余动作下次访问还是用原 URL。 比如服务器中临时维护某个 URL就可以返回 302 状态码。 URL 格式 URI 是统一资源标识符URL 是统一资源定位符URL 是 URI 的一种具体实现。 URL 格式schema://host:port/path schema协议名表示资源应该使用哪种协议来访问。如 http、https在 scheme 之后必须是三个特定的字符 ://它把 scheme 和后面的部分分离开host:port 在 :// 之后是资源所在的主机名即主机名加端口号path是资源在主机上的位置路径有了协议名和主机地址、端口号再加上后面标记资源所在位置的path浏览器就可以连接服务器访问资源了。 查询参数schema://host:port/path?keyvaluekeyvalue path 后面使用一个?“分割开来”?后面的就是query查询参数部分query部分是由“”拼接的多个keyvalue键值对 获取图片的时候想要指定不同大小仅用“协议名 主机名 路径”的方式是无法适应这些场景的所以 URI 后面还有一个 “query” 部分它在 path 之后用一个 “?” 开始但不包含 “?”表示对资源附加的额外要求。 片段标识 它是 URI 所定位的资源内部的一个“锚点”或者说是“标签”浏览器可以在获取资源后直接跳转到它指示的位置 但片段标识符仅能由浏览器这样的客户端使用服务器是看不到的。也就是说浏览器永远不会把带#fragment 的 URI 发送给服务器服务器也永远不会用这种方式去处理资源的片段。 URL 编码 在 URI 里只能使用 ASCII 码但如果要在 URI 里使用英语以外的汉语、日语等其他语言该怎么办呢 还有某些特殊的 URI会在 path、query 里出现“?等起界定符作用的字符会导致 URI 解析错误这时又该怎么办呢 URI 引入了编码机制对于 ASCII 码以外的字符集和特殊字符做一个特殊的操作把它们转换成与 URI 语义不冲突的形式。 URI 转义的规则有点“简单粗暴”直接把非 ASCII 码或特殊字符转换成十六进制字节值然后前面再加上一个“%”。 例如空格被转义成“%20”“?”被转义成“%3F”。而中文、日文等则通常使用 UTF-8 编码后再转义例如“银河”会被转义成 “%E9%93%B6%E6%B2%B3”。