当前位置:   article > 正文

JavaEE初阶(11)HTTP 协议(发展历程、报文格式、URL、HTTP请求详解、HTTP 响应详解、构造HTTP请求、form 表单构造、AJAX的方式构造)_java请求报文和响应报文的组装

java请求报文和响应报文的组装

接上次博客:JavaEE初阶(10)网络原理——TCP/IP协议(再谈协议、应用层、自定义协议、传输层:UDP 协议、 TCP协议、异常、TCP和UDP的对比、网络层重点协议、数据链路层重点协议)-CSDN博客

目录

HTTP 协议概念 

HTTP 协议发展历程 

适用场景

1. 浏览器打开网站:

2. 手机应用程序访问服务器:

HTTP的报文格式

HTTP协议的不同使用场景

下载并使用抓包工具

HTTP请求报文格式:

HTTP响应报文格式:​编辑

URL

认识 "方法" (method)

1、GET 方法

2、POST 方法

GET 和 POST 的区别(面试题)

HTTP其他方法

HTTP请求详解

认识请求 "报头" (header)

前期准备

登陆请求

登录请求头部

登录响应头部

响应主体

访问其他页面

GET请求头部

理解登陆过程

 认识请求 "正文" (body)

HTTP 响应详解

200 OK

404 Not Found

403 Forbidden

405 Method Not Allowed 

500 Internal Server Error

504 Gateway Timeout

302 Move temporarily

301 Moved Permanently 

418 I am a teapot!

状态码小结

认识响应 "报头" (header)

Content-Type

认识响应 "正文" (body) 

(1)text/html

(2)text/css

(3) application/javascript

(4)application/json

那么我们如何让客户端构造一个HTTP请求?如何让服务器处理一个HTTP请求?

浏览器构造HTTP请求:

服务器处理HTTP请求(具体的以后介绍):

通过 form 表单构造

form 发送 GET 请求

表单form的重要参数

输入字段 input 的重要参数

体会 form 代码和 HTTP 请求之间的对应关系

form 发送 POST 请求

通过AJAX的方式构造

发送 GET 请求

浏览器和服务器交互过程(引入 ajax 后):

发送 POST 请求

练习:


HTTP 协议概念 

HTTP是“超文本传输协议”(Hypertext Transfer Protocol)的缩写,它是一种应用层协议,用于在互联网上传输超文本文档,通常指的是网页。HTTP是Web上最基本的协议之一,它定义了客户端(例如Web浏览器)和服务器之间的通信规则,使我们能够在Web上浏览、搜索和与各种Web资源进行交互。

HTTP的主要功能包括:

  1. 传输数据:HTTP负责在客户端和服务器之间传输数据,通常是HTML文档、图像、样式表和其他Web资源。这些资源以超文本的形式链接在一起,构成了Web页面。

  2. 请求-响应模型:客户端通过HTTP请求发送到服务器,并等待服务器的HTTP响应。请求包括所需的资源,以及其他信息如请求方法(GET、POST、PUT、DELETE等),请求头(包含有关请求的元数据),以及请求体(对于某些方法,如POST)。

  3. 状态代码:HTTP响应包括一个状态代码,指示请求是否成功。例如,200表示成功,404表示未找到请求的资源,302表示重定向等。

  4. 无状态性:HTTP是一种无状态协议,这意味着每个HTTP请求都是独立的,不依赖于之前的请求。这使得Web服务器可以处理大量的并发请求,但也要求使用会话(如cookies)来跟踪用户状态。

  5. 可扩展性:HTTP是一个灵活的协议,可以轻松添加新的头部字段和方法,以支持不断发展的Web应用需求。

  6. 连接管理:HTTP/1.1引入了持久连接,允许多个请求和响应在单个TCP连接上进行,减少了连接的开销。

HTTP的版本有多个,目前最常用的是HTTP/1.1和HTTP/2.0。HTTP/2.0引入了更多的性能优化,如多路复用、头部压缩和服务器推送,以提高Web应用的加载速度和性能。

HTTP是Web的基础之一,负责连接客户端和服务器,使我们能够在浏览器中浏览、搜索和与Web上的各种资源进行交互。无论您是浏览网页、下载文件还是与Web应用程序进行通信,HTTP都在幕后起着至关重要的作用。

HTTP 协议发展历程 

HTTP 诞生与1991年,目前已经发展为最主流使用的一种应用层协议。

HTTP通常是基于传输层的TCP协议实现的,而HTTP/1.0、HTTP/1.1和HTTP/2.0都使用TCP作为其底层传输协议。HTTP/3.0则采用了基于UDP的QUIC(Quick UDP Internet Connections)协议。

HTTP/1.1和HTTP/2.0是当前最常用的HTTP版本:

  • HTTP/1.1:HTTP/1.1是目前广泛采用的HTTP版本,它建立在TCP连接之上,使用一系列请求-响应的模式来传输数据。HTTP/1.1引入了持久连接,允许多个请求和响应在单个TCP连接上复用,以减少连接的开销。然而,它仍然存在一些性能瓶颈,如"队头阻塞",这在HTTP/2.0中得到了改善。

  • HTTP/2.0:HTTP/2.0是HTTP/1.1的进化版本,它引入了多路复用、头部压缩、服务器推送等特性,以提高性能和减少加载时间。HTTP/2.0仍然基于TCP,但通过并行处理多个请求,解决了HTTP/1.1中的队头阻塞问题。

HTTP/3.0采用了UDP上的QUIC协议,以进一步提高性能和安全性。QUIC是由Google开发的协议,它允许多个流(包括HTTP请求和响应)在同一连接上独立传输,降低了延迟。此协议还包括一层加密,从而提高了安全性。然而,HTTP/3.0尚未被广泛采用,而HTTP/1.1和HTTP/2.0仍然是大多数Web应用的主要版本。

总的来说,不同版本的HTTP都在不断发展和改进,以适应不断增长的互联网应用需求。选择使用哪个版本通常取决于你的应用需求和支持的技术。在实际应用中,往往需要综合考虑性能、兼容性和安全性等因素来选择合适的HTTP版本。

适用场景

HTTP协议在许多不同的场景中都得到了广泛的应用,其中包括浏览器打开网站和手机应用程序访问服务器。以下是这两种常见情况的简要说明:

1. 浏览器打开网站:

当我们在Web浏览器中输入网站地址或点击书签时,会发生以下过程:

  • 浏览器将发送一个HTTP请求到目标网站的服务器,请求指定的网页或资源。

  • 目标服务器接收到请求后,会根据请求的路径和其他信息查找并准备要发送的资源。

  • 服务器会构建HTTP响应,其中包括所请求资源的内容以及一些元数据,如响应状态代码、响应头(包含有关响应的元信息)等。

  • 服务器将HTTP响应发送回浏览器。

  • 浏览器接收响应后,会解析响应内容,渲染页面并显示在用户的屏幕上。

  • 用户可以与网页交互,点击链接、填写表单等。

这是典型的HTTP协议用例,其中HTTP用于在浏览器和服务器之间传输网页和相关资源。

2. 手机应用程序访问服务器:

移动应用程序通常需要与服务器通信来获取数据、更新内容、进行用户身份验证等。在这种情况下,HTTP通常用于构建移动应用程序与服务器之间的通信。

  • 移动应用程序会使用HTTP请求与服务器交互。这可以包括GET请求来获取数据、POST请求来提交表单数据或执行其他操作,以及其他HTTP方法。

  • 服务器将处理这些请求,执行相关操作,然后构建HTTP响应,将所需的数据或响应状态返回给应用程序。

  • 移动应用程序将解析HTTP响应,处理数据,然后在用户界面上呈现或执行适当的操作。

这种情况下,HTTP用于支持移动应用程序与服务器之间的数据交换,使应用程序能够实时获取和展示数据。

总的来说,HTTP是一种通用的协议,适用于各种互联网应用。无论是通过浏览器访问网站还是通过移动应用程序与服务器通信,HTTP都是连接客户端和服务器的关键技术之一。

当然,我们要学习HTTP的协议,重点还是学习HTTP的报文格式,接下来就让我们主要来看看HTTP的报文格式。

HTTP的报文格式

HTTP协议的不同使用场景

根据不同的交互需求,HTTP可以被用于不同的模式:

  1. 一问一答访问网站:这是HTTP最常见的使用方式,通常用于浏览网站。客户端(通常是Web浏览器)向服务器发送HTTP请求,请求网页或资源,服务器返回相应的HTTP响应,包含所请求的内容。这是典型的请求-响应模式,客户端请求一个资源,服务器响应提供该资源。

  2. 多问一答上传文件:在这种情况下,客户端需要上传文件到服务器。客户端使用HTTP请求,通常是使用HTTP POST方法,将文件数据作为请求体发送到服务器。服务器接收到请求后,可以将文件保存在服务器上,然后返回一个表示上传成功的HTTP响应。

  3. 一问多答下载文件:这是当客户端需要从服务器下载文件时的模式。客户端向服务器发送HTTP请求,请求服务器提供特定的文件或资源。服务器返回文件内容作为HTTP响应体,客户端可以下载并保存该文件。

  4. 多问多大串流/远程桌面:这是一种更复杂的应用程序场景,其中HTTP用于建立多个请求和响应的串流通信。这可以是多个请求和响应,以进行复杂的交互,也可以是远程桌面协议,使远程控制和屏幕共享成为可能。

理解HTTP协议的报文格式对于有效地使用和分析HTTP通信至关重要。HTTP协议是一种基于"一问一答"结构模型的协议,它用于在客户端和服务器之间传输超文本文档和其他资源。客户端向服务器发送HTTP请求报文,服务器接收请求并发送HTTP响应报文作为响应。

和我们之前学的TCP和UDP相对比,它的请求和响应在协议格式上有一些差异,主要体现在报文的结构和内容上。

以下是HTTP请求和响应报文的基本格式:

下载并使用抓包工具

如何查看到HTTP请求和响应的格式呢?

我们需要抓包工具:把网卡上经过的数据获取到并显示出来,它们是分析调试的程序的重要手段。

这些工具可以拦截、捕获和分析经过网络接口的数据流,包括HTTP请求和响应。以下是一些常用的抓包工具:

  1. Wireshark:Wireshark是一款流行的开源网络分析工具,可以捕获网络数据包并以易于理解的形式显示它们。我们可以使用Wireshark来查看HTTP请求和响应的详细信息,包括请求报文、响应报文、报文头和报文体,但是不太方便。

  2. Fiddler:Fiddler是一个Windows平台上的免费Web调试代理工具,专注于HTTP调试。它可以捕获HTTP请求和响应,以及WebSocket通信。Fiddler还提供了详细的请求和响应的解析、筛选和修改功能。

  3. Charles:Charles是一款跨平台的HTTP代理工具,用于查看HTTP请求和响应以及进行调试。它允许我们查看和修改流经代理的数据,从而可以分析和调试HTTP通信。

  4. Postman:Postman是一个强大的API测试和调试工具,可以捕获和查看HTTP请求和响应。虽然它主要用于API测试,但也可以用于HTTP请求的查看和调试。

接下来我们就使用 Fiddler 来讲解。

Fiddler是一个强大的网络调试代理工具,它的界面通常分为左侧和右侧两个部分,用于查看捕获的HTTP请求和响应。

左侧部分是一个包含捕获的HTTP请求和响应的列表,我们可以在这里查看所有经过Fiddler代理的数据包,这些数据包按时间顺序排列。

右侧部分通常用于显示选定请求或响应的详细信息,包括请求头、响应头、报文体等。这个部分用于分析特定的请求或响应的内容。

  1. 启用HTTPS抓包功能

    • 打开Fiddler。
    • 在Fiddler的菜单栏中,选择“Tools”(工具) > “Options”(选项)。
    • 在选项对话框中,选择“HTTPS”选项卡。
    • 在该选项卡下,勾选“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”选项。
  2. 安装Fiddler根证书

    • 一旦你启用了HTTPS抓包功能,Fiddler会充当中间代理,要能够解密HTTPS流量,就需要安装Fiddler根证书。
    • 在Fiddler选项对话框的“HTTPS”选项卡下,单击“Actions”(操作)。
    • 在下拉菜单中,选择“Trust Root Certificate”(信任根证书)。
    • 按照提示,将Fiddler根证书安装到你的操作系统或浏览器中。这将允许Fiddler解密HTTPS流量并进行分析。
  3. 开始抓包

    • 确保Fiddler已经启动并配置为捕获HTTPS流量。
    • 打开任何浏览器或应用程序,执行你希望分析的操作,以触发HTTPS流量。
    • 在Fiddler的左侧列表中,你将看到捕获的请求和响应,包括HTTP和HTTPS的内容。
    • 单击每个请求或响应,以查看详细信息,包括请求报文和响应报文。

注意,安装Fiddler根证书可能需要管理员权限,并且在某些操作系统和浏览器中,你可能需要额外的配置步骤。一旦配置完成,就可以使用Fiddler来分析HTTPS流量,检查请求和响应的详细信息,以及进行网络调试。

安装的 Fiddler 需要手动开启HTTP功能,并且安装证书,否则只能抓http。

安装根证书,一定要选择“同意”,否则你就只能卸载重装了: 

 把该勾选的项都勾选上:

这样就正常了:

但是Fiddler 本质上是一个“代理”,可能会和其他的代理软件冲突。

Fiddler在其核心上是一个正向代理服务器,用于HTTP和HTTPS网络调试。它充当客户端(例如Web浏览器)和目标服务器之间的中间人,允许开发人员捕获、查看和修改这两方之间的交互数据。

正向代理和反向代理是两种代理服务器的不同用途:

  1. 正向代理(Forward Proxy):

    • 正向代理是代理服务器,代表客户端发起请求,以隐藏客户端的身份或绕过防火墙等网络安全限制。
    • 客户端(例如,浏览器)配置正向代理服务器的地址和端口,然后将请求发送到代理服务器。代理服务器代表客户端发起请求,接收响应,然后将响应返回给客户端。
    • 正向代理充当客户端的中介,客户端的请求似乎是来自代理服务器而不是客户端自身。这可用于访问受限制的内容或绕过网络过滤。
  2. 反向代理(Reverse Proxy):

    • 反向代理是代理服务器,代表服务器接收请求,并将请求路由到后端服务器以获取响应,然后将响应返回给客户端。
    • 客户端向反向代理服务器发出请求,但客户端不知道或不需要知道响应来自哪个后端服务器。
    • 反向代理通常用于负载均衡、安全性和性能优化,将客户端的请求分发给多个后端服务器以提高性能,并隐藏后端服务器的身份以增强安全性。

以下是Fiddler作为正向代理的程序过程:

  1. 当你启动Fiddler时,它会开始监听指定的端口(默认为8888)。
  2. 你需要在浏览器或其他需要监视的应用程序中,将Fiddler设置为正向代理。通常,这意味着你将网络设置中的代理指向127.0.0.1(本地主机)的端口8888。
  3. 当你的浏览器或应用程序发起一个网络请求时,请求首先发送到Fiddler。
  4. Fiddler捕获请求并在其用户界面中显示详细信息。在此阶段,开发人员可以查看或修改请求内容。一旦完成,Fiddler将请求转发到目标服务器。
  5. 目标服务器处理请求并将响应发送回Fiddler。
  6. Fiddler捕获响应并在其用户界面中显示。开发人员可以查看或修改响应内容。一旦完成,Fiddler将响应转发回原始客户端(例如浏览器)。
  7. 浏览器或应用程序接收到响应,并根据响应数据进行相应的处理。

 Fiddler 用于中继HTTP请求和响应,以便分析和调试网络通信。由于它的代理特性,可能与其他代理软件或配置的代理服务产生冲突。

冲突和如何解决它们的方法:

  1. 冲突的代理设置:如果您的计算机上已经配置了其他代理服务(如VPN代理、代理服务器软件等),它们可能会与Fiddler产生冲突。在这种情况下,你可以考虑暂时禁用其他代理服务,以便Fiddler能够正常工作。

  2. 端口冲突:Fiddler默认监听的端口是8888,如果其他代理服务或应用程序正在使用相同的端口,可能会导致冲突。你可以在Fiddler选项中更改Fiddler的监听端口,以避免与其他服务冲突。

  3. 安全软件干预:某些安全软件可能会检测到代理行为,并视其为潜在风险。这可能导致安全软件干预Fiddler的操作。你可以在安全软件中配置允许Fiddler运行,并排除其干预。

  4. 操作系统代理设置:在某些操作系统中,代理设置可能会全局影响网络连接。如果Fiddler设置为全局代理,它可能会与其他代理设置产生冲突。确保Fiddler的代理设置仅用于需要调试的应用程序。

解决这些冲突通常需要一些配置调整和可能的冲突排除。在使用Fiddler之前,你可以检查你的计算机上是否有其他代理服务或代理设置,并确保它们不会干扰Fiddler的正常运行。

平常我们见过的一些程序,比如:VPN和加速器,这些都是“代理”,它们都会冲突。所以你应该先关闭之前的一些代理软件,也有可能是一个浏览器插件。你还可以尝试使用不同的浏览器,edge通常会有点问题。

为了方便观察,我们先清空一下原先的数据列表:

CTRL+A全选,

选择 "Edit" 菜单中的 "Remove" 选项,或者使用键盘上的 Delete 键。这将删除你选择的HTTP请求数据。

如果你删除了某个请求但后来需要查看或分析它,你可以在 "File" 菜单中找到 "Restore" 选项来恢复已删除的请求。

一个网站打开的时候往往不是只和服务器进行一次操作,大概率是多次操作。

在Fiddler中,HTTP请求和响应的颜色编码通常是用来区分不同类型的请求和响应的状态。

一般情况下,Fiddler的颜色编码如下:

  • 蓝色:通常表示返回的是HTML内容,也就是网页的主体部分。HTML通常是由文本、标记和链接组成的,用于呈现网页的结构和内容。
  • 黑色:通常表示其他类型的数据,例如JSON、XML、纯文本或二进制数据,这些数据可以用于各种不同的应用,如API通信、文件传输等。
  • 绿色:表示成功的HTTP请求。
  • 红色:表示HTTP请求失败或返回错误状态码,如404(未找到)或500(服务器内部错误)。
  • 黄色:表示重定向的请求,即服务器返回了重定向状态码,如302(临时重定向)。
  • 灰色:表示请求是被缓存的。
  • 紫色:表示WebSocket通信。

这些颜色编码有助于用户迅速识别HTTP请求和响应的状态和类型。例如,红色的请求和响应通常表示问题或错误,绿色的请求和响应表示成功,黄色表示重定向,等等。这使得Fiddler成为一个强大的网络调试工具,有助于开发人员分析和解决与HTTP通信相关的问题。

HTTP协议是文本格式的协议,我们点开协议里面的HTTP请求部分,会发现内容都是字符串。

我们之前学的TCP和UDP、IP都是二进制。

HTTP响应其实也是文本的,但是直接查看我们看到的是二进制文件,因为这里是压缩后的。

HTTP响应经常会被压缩,压缩之后体积会变小,传输的时候节省网络带宽。

解压缩点这个按钮:

 

解压缩之后可以看到响应的数据其实是HTML。浏览器显示的网页就是HTML,往往都是浏览器先请求对应的服务器,从服务器那边拿到的页面数据。 

HTTP请求报文格式

  1. Server: openresty
  2. Date: Thu, 19 Oct 2023 12:41:06 GMT
  3. Content-Type: text/html
  4. Connection: keep-alive
  5. Set-Cookie: seedcode=9598557; path=/; Expires=Thu, 19-Oct-23 12:46:06 GMT
  6. Set-Cookie: fingerprint=7e4fd68bf40a423ceff6a9b72f2e139e; path=/; Expires=Thu, 19-Oct-23 12:46:06 GMT
  7. Content-Length: 504
  8. <html><body><noscript><h1 style="text-align:center;color:red"><strong>Please turn on JavaScript</strong></h1></noscript><script>var setCookie=function(e,o,t){var r=new Date;r.setDate(r.getDate()+t),document.cookie=e+"="+o+";expires="+r};function getCookie(e){for(var o=document.cookie.split("; "),t=0;t<o.length;t++){var r=o[t].split("=");if(r[0]===e)return r[1]}return!1}setCookie("checkcode",Math.floor(3.14*Math.sqrt(1*getCookie("seedcode")))),location.href="/post/1058.html"</script></body></html>
  1. GET /index.html HTTP/1.1
  2. Host: www.example.com
  3. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
  4. Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8

HTTP请求报文由以下几部分组成:

  1. 请求行:包括HTTP方法(GET、POST、PUT、DELETE等)、请求的URI(Uniform Resource Identifier,即请求的路径),以及HTTP协议版本(通常是HTTP/1.1)。

  2. 请求头:包含请求的元数据,如User-Agent(客户端的用户代理)、Host(请求的目标主机名)、Accept(客户端可以接受的响应媒体类型)等。

  3. 空行:用于分隔请求头和请求体。

  4. 请求体(可选):包含请求的数据,通常在HTTP方法是POST或PUT时使用,例如表单数据或上传的文件。

从行的角度来看:

  1. 首行

    • 第一部分是HTTP请求的方法(GET、POST、PUT等),它指示了客户端希望执行的操作。
    • 第二部分是URL(Uniform Resource Locator),描述了所请求资源在网络上的位置。
    • 第三部分是HTTP协议的版本号,例如,HTTP/1.1。
  2. 请求头(Header):

    • 请求头是一系列键值对,每一对键值对都描述了请求的元数据信息。键和值之间使用冒号和空格分隔,如Host: www.example.com。
    • 请求头用于传递客户端的信息和需求,如User-Agent、Accept、Cookie等。
  3. 空行

    • 空行是请求头的结束标记,它表示请求头部分的结束。
  4. 请求正文(Body):

    • 请求正文是可选的,它包含请求的数据,如表单提交的数据或上传的文件内容。
    • 并非所有HTTP请求都包含请求正文。

HTTP响应报文格式

  1. HTTP/1.1 200 OK
  2. Server: openresty
  3. Date: Thu, 19 Oct 2023 12:41:10 GMT
  4. Content-Type: text/html; charset=utf-8
  5. Connection: keep-alive
  6. Set-Cookie: checkcode=9728; path=/; Expires=Fri, 20-Oct-23 12:41:06 GMT
  7. Set-Cookie: seedcode=9598557; path=/; Expires=Fri, 20-Oct-23 12:41:06 GMT
  8. Set-Cookie: fingerprint=7e4fd68bf40a423ceff6a9b72f2e139e; path=/; Expires=Fri, 20-Oct-23 12:41:06 GMT
  9. Product: Z-BlogPHP 1.7.3
  10. X-XSS-Protection: 1; mode=block
  11. Upgrade-Insecure-Requests: 1
  12. Content-Length: 47507
  13. <!DOCTYPE html>
  14. <html lang="zh-CN">
  15. <head>
  16. <meta charset="utf-8">
  17. <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
  18. <title>中国大学mooc现代邮政英语(English for Modern Postal Service)_网课宝盒</title>
  19. <link href="https://www.wangkebaohe.com/zb_users/theme/Hidiy/style/main.css?v=2.4.2" rel="stylesheet">
  20. <link href="https://www.wangkebaohe.com/zb_users/theme/Hidiy/css/font-awesome.min.css?v=4.7" rel="stylesheet">
  21. <style type="text/css">
  22. a:hover,.mcolor{color:#F4791F}
  23. .topmenu .bar>li.current>a,.bx_pager a:hover,.bx_pager a.active,.swiper-pagination-bullet-active{background:#F4791F}
  24. .topmenu,.cmslist .xyti,#footerbar{background:#333D46}
  25. .logcon h1,.logcon h2,.logcon h3,.logcon h4,.logcon h5,.logcon h6,.vplist .xyti h3,#footerbar{border-color:#F4791F}
  26. .topbox{background:#E5E5E5}
  27. </style>
  28. <script src="https://www.wangkebaohe.com/zb_system/script/jquery-2.2.4.min.js"></script>
  29. <script src="https://www.wangkebaohe.com/zb_system/script/zblogphp.js"></script>
  30. <script src="https://www.wangkebaohe.com/zb_system/script/c_html_js_add.php"></script>
  31. <link rel="stylesheet" href="https://www.wangkebaohe.com/zb_users/plugin/tx_info_pay/css/style.css?t=2023-05-26">
  32. <link href="https://www.wangkebaohe.com/zb_users/plugin/Jsctrl_vip/style.php" rel="stylesheet">
  33. <script src="https://www.wangkebaohe.com/zb_users/plugin/Jsctrl_vip/script.php"></script>
  34. <script src="https://www.wangkebaohe.com/zb_users/plugin/Jsctrl_vip/js/jsctrl.js?v=4.2"></script>
  35. </head>
  36. <body>
  37. <div id="topnav">
  38. <div class="wrap">
  39. <div class="tnlt">中国大学mooc现代邮政英语(English for Modern Postal Service)</div>
  40. <div class="tnrt">
  41. <a href="javascript:;" id="zh_big">繁體中文</a><a href="javascript:;" class="showhistory">浏览记录</a>
  42. </div>
  43. <div class="historybox">
  44. <h5>您已经看过</h5><i></i><b></b>
  45. <a href="javascript:;" class="h-del">[清空]</a>
  46. <ul id="hislist"></ul>
  47. </div>
  48. </div>
  49. <div class="minav"><i class="fa fa-navicon"></i></div>
  50. </div>
  51. <div class="wrap">
  52. <div class="maintop">
  53. <div class="mlogo"><a href="https://www.wangkebaohe.com/" title="网课宝盒"><img src="https://www.wangkebaohe.com/zb_users/upload/2019/11/201911281574910414401856.png" alt="网课宝盒"></a>
  54. </div>
  55. <div class="topsh">
  56. <form action="https://www.wangkebaohe.com/zb_system/cmd.php?act=search" name="search" method="post">
  57. <input name="q" type="text" value="查文找字,善用搜索..." class="hdin" onFocus="if(value==defaultValue){value='';}" onBlur="if(!value){value=defaultValue;}"><input type="submit" value="搜索一下" class="hbtn">
  58. </form>
  59. </div>
  60. </div>
  61. <div class="topmenu">
  62. <ul class="bar">
  63. <li id="nvabar-item-index"><a href="https://www.wangkebaohe.com/">首页</a></li><li id="navbar-category-3"><a href="https://www.wangkebaohe.com/category-3.html">其他慕课</a></li><li id="navbar-category-4"><a href="https://www.wangkebaohe.com/category-4.html">网站公告/常见问题</a></li><li id="navbar-category-1"><a href="https://www.wangkebaohe.com/category-1.html">超星尔雅学习通</a></li><li id="navbar-category-2"><a href="https://www.wangkebaohe.com/category-2.html">智慧树知到</a></li> </ul>
  64. <span class="navi-fa">fa-home|fa-star-o</span>
  65. </div>
  66. </div>
  67. <div class="wrap">
  68. <dl class="function" id="divComments">
  69. <dt class="function_t">最新留言</dt><dd class="function_c">
  70. <ul><li><a href="https://www.wangkebaohe.com/post/5950.html#cmt443" title="访客 @ 2023-04-19 17:33:05">掐指一算,此文必火,果断收藏!</a></li>
  71. <li><a href="https://www.wangkebaohe.com/post/1076.html#cmt406" title="访客 @ 2022-12-04 22:18:38">真好</a></li>
  72. <li><a href="https://www.wangkebaohe.com/post/2958.html#cmt399" title="访客 @ 2022-11-21 09:14:20">厉害</a></li>
  73. <li><a href="https://www.wangkebaohe.com/post/1752.html#cmt313" title="访客 @ 2021-12-28 01:07:59">真好</a></li>
  74. <li><a href="https://www.wangkebaohe.com/post/1829.html#cmt309" title="访客 @ 2021-12-16 23:56:01">大学计算机基础</a></li>
  75. <li><a href="https://www.wangkebaohe.com/post/1820.html#cmt282" title="访客 @ 2021-11-20 20:38:00">曾经沧海难为水,鱼香肉丝配鸡腿。我是来打酱油的…</a></li>
  76. <li><a href="https://www.wangkebaohe.com/post/1603.html#cmt281" title="访客 @ 2021-11-17 17:29:46">掐指一算,此文必火,果断收藏!</a></li>
  77. <li><a href="https://www.wangkebaohe.com/post/1748.html#cmt256" title="访客 @ 2021-10-16 13:42:27">很好很强大</a></li>
  78. <li><a href="https://www.wangkebaohe.com/post/1604.html#cmt251" title="访客 @ 2021-09-29 08:11:38">答案</a></li>
  79. </ul>
  80. </dd>
  81. </dl>
  82. <dl class="function" id="divCatalog">
  83. <dt class="function_t">网站分类</dt><dd class="function_c">
  84. <ul><li><a title="超星尔雅学习通" href="https://www.wangkebaohe.com/category-1.html">超星尔雅学习通</a></li>
  85. <li><a title="智慧树知到" href="https://www.wangkebaohe.com/category-2.html">智慧树知到</a></li>
  86. <li><a title="其他慕课" href="https://www.wangkebaohe.com/category-3.html">其他慕课</a></li>
  87. <li><a title="网站公告/常见问题" href="https://www.wangkebaohe.com/category-4.html">网站公告/常见问题</a></li>
  88. <li><a title="中国大学慕课" href="https://www.wangkebaohe.com/category-5.html">中国大学慕课</a></li>
  89. <li><a title="学堂在线答案" href="https://www.wangkebaohe.com/category-11.html">学堂在线答案</a></li>
  90. </ul>
  91. </dd>
  92. </dl>
  93. <dl class="function" id="divPrevious">
  94. <dt class="function_t">最近发表</dt><dd class="function_c">
  95. <ul><li><a title="知到智慧树大学英语写作网络课程单元测试答案" href="https://www.wangkebaohe.com/post/6208.html">知到智慧树大学英语写作网络课程单元测试答案</a></li>
  96. <li><a title="网课知到国家安全教育智慧树答案 山东大学(威海)" href="https://www.wangkebaohe.com/post/6207.html">网课知到国家安全教育智慧树答案 山东大学(威海)</a></li>
  97. <li><a title="超星尔雅军事理论(上海财经大学版)2023网课答案" href="https://www.wangkebaohe.com/post/403.html">超星尔雅军事理论(上海财经大学版)2023网课答案</a></li>
  98. <li><a title="网课知到西方影视欣赏智慧树答案" href="https://www.wangkebaohe.com/post/6205.html">网课知到西方影视欣赏智慧树答案</a></li>
  99. <li><a title="网课知到器官系统整合 呼吸、循环、血液系统基础智慧树答案" href="https://www.wangkebaohe.com/post/6204.html">网课知到器官系统整合 呼吸、循环、血液系统基础智慧树答案</a></li>
  100. <li><a title="2023年秋季学期新疆电大一体化中华文化概说平时作业1-4答案" href="https://www.wangkebaohe.com/post/6203.html">2023年秋季学期新疆电大一体化中华文化概说平时作业1-4答案</a></li>
  101. </li>
  102. </ul>
  103. </dd>
  104. </dl>
  105. <dl class="function" id="divArchives">
  106. <dt class="function_t">文章归档</dt><dd class="function_c">
  107. </dd>
  108. </dl> </div>
  109. </div>
  110. </div>
  111. <div id="footerbar">
  112. <div class="wrap">
  113. <a href="https://www.wangkebaohe.com/">网课宝盒</a> &copy;<script>document.write(new Date().getFullYear());</script> All Rights Reserved. &nbsp;联系我们:QQ 997755178<br /><script>
  114. var _hmt = _hmt || [];
  115. (function() {
  116. var hm = document.createElement("script");
  117. hm.src = "https://hm.baidu.com/hm.js?e1c24c1c6d38294029404f3731fd3890";
  118. var s = document.getElementsByTagName("script")[0];
  119. s.parentNode.insertBefore(hm, s);
  120. })();
  121. </script>
  122. <a href="https://beian.miit.gov.cn/">蜀ICP备18035410号-3</a>|<a href="https://www.wangkebaohe.com/map/sitemap_one_tag.html" target="_self">网站标签</a>|<a href="https://www.wangkebaohe.com/map/sitemap_one_post.html" target="_self">站点地图</a>|<script>(function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s);})();</script><br />
  123. <span class="fta"></span>
  124. </div>
  125. </div>
  126. <link rel="stylesheet" href="https://www.wangkebaohe.com/zb_users/theme/Hidiy/css/lightgallery.min.css">
  127. <script src="https://www.wangkebaohe.com/zb_users/theme/Hidiy/script/lightgallery-all.min.js"></script>
  128. <script>
  129. var rcmsg="掐指一算,此文必火,果断收藏!||大家千万要冷静,别乱来啊||曾经沧海难为水,鱼香肉丝配鸡腿。我是来打酱油的…";
  130. $(function(){
  131. $(".logwrap img").each(function(){
  132. var path = $(this).attr("src");
  133. var width = $(this).width();
  134. if(width >= 200 && !$(this).parent("a").length){
  135. $(this).wrap('<a href="'+path+'" class="lightgallery"></a>');
  136. }
  137. });
  138. setTimeout(function () {
  139. $(".logcon").lightGallery({
  140. thumbnail: false,
  141. selector: '.lightgallery'
  142. });
  143. }, 800);
  144. });
  145. </script>
  146. <script src="https://www.wangkebaohe.com/zb_users/theme/Hidiy/script/jquery.lazyload.min.js"></script>
  147. <script src="https://www.wangkebaohe.com/zb_users/theme/Hidiy/script/main.js?v=2.4.2"></script>
  148. <script>
  149. var defaultEncoding = "2";
  150. var translateDelay = "50";
  151. var cookieDomain = "https://www.wangkebaohe.com/";
  152. var msgToTraditionalChinese = "<b>繁體中文</b>";
  153. var msgToSimplifiedChinese = "<b>简体中文</b>";
  154. var translateButtonId = "zh_big";
  155. </script>
  156. <script src="https://www.wangkebaohe.com/zb_users/theme/Hidiy/script/zh_big.js"></script>
  157. <script>translateInitilization();</Script>
  158. <div class="share-up">
  159. <div class="backtop"><span class="fa fa-angle-up"></span></div>
  160. <div style="display:none"><div class="tx-info-pay-error-tips4"><p>你输入的数据有误,请确认!</p><p>如已购买,但查不到</p><p>可联系客服QQ 55089918 进行核实</p></div></div>
  161. </body>
  162. </html><!--4,238.80 ms , 12 queries , 2277kb memory , 0 error-->

  1. HTTP/1.1 200 OK
  2. Date: Thu, 20 Jan 2022 15:50:23 GMT
  3. Server: Apache/2.4.41 (Ubuntu)
  4. Content-Length: 1234
  5. Content-Type: text/html
  6. <!DOCTYPE html>
  7. <html>
  8. <head>
  9. <title>Example Page</title>
  10. </head>
  11. <body>
  12. <h1>Hello, World!</h1>
  13. </body>
  14. </html>

HTTP响应报文由以下几部分组成:

  1. 状态行:包括HTTP协议版本(通常是HTTP/1.1)、状态码(指示请求的处理结果,如200表示成功,404表示未找到,302表示重定向等)和状态短语(与状态码相关的短描述)。

  2. 响应头:包含响应的元数据,如Server(响应的服务器软件)、Content-Type(响应的媒体类型)、Content-Length(响应的内容长度)等。

  3. 空行:用于分隔响应头和响应体。

  4. 响应体:包含响应的数据,通常是网页内容、文件内容或其他资源的数据。

 从行的角度来看:

  1. 首行

    • 第一部分是HTTP协议的版本号,例如,HTTP/1.1。
    • 第二部分是状态码,它描述了请求的处理结果,如200表示成功、404表示未找到、302表示重定向等。
    • 第三部分是状态码的描述,通常是一个短的文本说明,例如"OK"表示成功。
  2. 响应头(Header):

    • 响应头也是一系列键值对,描述了响应的元数据信息,如Server、Content-Type、Content-Length等。
    • 响应头传递了服务器的信息以及响应的属性。
  3. 空行

    • 空行标志着响应头的结束。
  4. 响应正文(Body):

    • 响应正文包含了响应的具体内容,这可能是HTML、CSS、JavaScript、JSON、XML等各种格式,也可以被压缩以减小传输大小。
    • 不一定要有,也可以为空。

URL

计算机中非常重要的概念。表述了某个资源在网络上的所属位置。数据库也算是一种资源。

https://user:pass@www.example.com:8080/directory/file.html?query=value#fragment

现在,让我们逐个拆解这个URL:

  1. 协议方案名(Scheme):  https: 这指明了用于访问资源的协议类型。常见的协议有http(超文本传输协议)、https(安全的HTTP,通过SSL/TLS加密)、ftp(文件传输协议)等。
  2. 登陆信息认证:这个东西现在基本上不会用了,尤其是针对用户的产品。
  3. 服务器地址【可以是IP地址,也可以是域名(Host)】: www.example.com: 这是服务器的域名,它指向了资源所在的服务器的位置。域名通常解析为一个IP地址。
  4. 服务器端口: 8080: 这是服务器上的特定端口,用于访问服务器上的特定服务。如果没有明确指定,大多数协议都有默认端口,例如HTTP的默认端口是80,而HTTPS的默认端口是443。
  5. 带层次的文件路径(Path): /directory/file.html: 这指定了服务器上资源的特定位置。路径通常对应服务器文件系统中的文件或目录结构,但这取决于服务器如何配置。
  6. 查询参数(Query): query=value: 这是发送给服务器的参数,通常用于请求特定资源或信息。查询参数以?开始,多个参数之间用&分隔。
  7. 片段(Fragment)标识符: #fragment: 这是URL中的一个锚点,它引用资源中的一个特定部分,例如HTML页面中的一个特定段落或标题。片段部分在浏览器中处理,并且通常不发送到服务器。

综上,URL提供了一个标准方法来描述互联网上资源的位置,并为客户端提供了所需的所有信息来定位和检索这些资源。

对于Query String来说,当查询参数的值(value)包含特殊字符、空格、或者非标准ASCII字符时,通常需要进行URL编码(URL encoding)以确保它们在URL中传输和解析正确。这些特殊符号可能会使浏览器/HTT[服务器对于URL的解析出错。所以我们需要进行转义。URL encode本质就是一种“转义字符”。

URL编码将特殊字符和非标准字符转换为URL安全的形式,通常是使用百分号编码(Percent Encoding)来表示。

URL编码的一般规则是将字符转换为"%XX"的形式,其中XX是字符的十六进制ASCII码。例如,空格字符会被编码为"%20",而问号字符?会被编码为"%3F"。这确保了URL中的字符不会与URL的语法和解析发生冲突。

例如,如果你想在查询参数中包含一个特殊字符,比如问号?,你应该将它编码为%3F,如下所示:

原始URL:https://www.example.com/search?q=some?query

编码后的URL:https://www.example.com/search?q=some%3Fquery

在不同的编程语言和框架中,都提供了URL编码和解码的函数或方法来处理这些情况。例如,Python中的urllib.parse库提供了quote()函数用于URL编码,以及unquote()函数用于解码。在JavaScript中,encodeURIComponent()函数用于URL编码,而decodeURIComponent()函数用于解码。

认识 "方法" (method)

1、GET 方法

定义与用途:

  • GET是HTTP中的一种方法,主要用于从服务器获取资源。
  • 在浏览器地址栏直接输入URL时,浏览器会发送一个GET请求。
  • 在HTML中,link、img、script 等标签也会触发GET请求。
  • 使用JavaScript的Ajax技术,我们可以构造GET请求进行异步数据交互。(Python爬虫常用)

请求特点:

  • 请求行的首部包含“GET”关键字。
  • URL的查询字符串可以有内容,也可以为空。
  • 请求头部分包含一系列的键值对结构。
  • GET请求的主体部分通常为空。

关于GET请求的URL长度问题:

  • 一些流传的信息认为GET请求的URL长度限制为1024kb,但这是不准确的。
  • HTTP协议的RFC 2616标准并未规定URL的最大长度。
  • URL的实际长度限制取决于浏览器和服务器的实现。
    • 浏览器端:不同浏览器对URL的长度限制不同。但现代浏览器通常都支持非常长的URL。
    • 服务器端:URL长度通常是可配置的,取决于服务器的设置和实现。

总之,尽管HTTP协议本身没有限制URL的长度,但在实际应用中,浏览器和服务器的具体实现可能会设置一些限制。在设计Web应用时,考虑到跨浏览器和跨平台的兼容性,通常建议不要使用过长的URL。

2、POST 方法

定义与用途:

  • POST是HTTP中的一种方法,通常用于将用户输入的数据提交给服务器,例如登录表单。
  • 通过HTML的 form 标签,或使用JavaScript的Ajax技术,都可以构造POST请求。

这里我其实最开始没能抓到返回页面的请求,原因是命中了浏览器缓存。

浏览器显示的页面其实都是从服务器这边下载的HTML,它的内容可能比较多,体积比较大,通过网络加载消耗的时间也会比较多。

所以浏览器一般都会自己带有缓存,就把之前加载过的页面保存在本地硬盘上,下次访问可以直接读取本地硬盘的数据。 

请求特点:

  • 请求行的首部包含“POST”关键字。
  • URL的查询字符串通常为空,但也可以包含数据。
  • 请求头部分包含一系列的键值对结构。
  • POST请求的主体部分通常不为空,主体内的数据格式由请求头中的 Content-Type 指定。
  • 主体的长度由请求头中的 Content-Length 指定。

POST方法主要用于将数据传输到服务器,这些数据通常包含在请求主体中。与GET请求不同,POST请求通常用于非幂等操作,例如在服务器上创建新资源,因此具有状态更改的潜力。在POST请求中,主体的数据格式通常由 Content-Type 头部字段指定,可以是表单数据、JSON、XML等格式。

你会发现我上传了一张图片,这里的body非常长,因为此处把图片放到HTTP请求中,往往要进行mb4转码

在HTTP请求中上传一张图片,这可能导致请求主体(body)非常大,因为图像文件通常具有较大的文件大小。如果将图像文件作为HTTP请求的一部分上传,可能需要将二进制数据进行编码,以便在HTTP请求中传输。

常用的图像编码格式包括Base64编码,这将二进制数据编码为文本字符串,使其可以包含在HTTP请求中。具体的编码方法和格式可能因不同的编程语言和HTTP库而异。通常,编码后的图像数据会放在请求的主体中,而请求头会包含有关数据类型(例如Content-Type)和数据长度(例如Content-Length)的信息。

在服务器端,我们需要解码请求主体,以还原图像文件的二进制数据。这可以通过编程语言的库和工具来完成。

注意,虽然可以将图像文件包含在HTTP请求中,但对于大型文件或多个文件的上传,通常更常见的做法是使用多部分表单(multipart/form-data),这样可以更有效地处理文件上传。此外,HTTP服务器通常有文件上传限制,需要根据服务器配置来确定最大请求主体的大小。

GET 和 POST 的区别(面试题)

GET和POST其实并没有本质的区别!!!双方可以替换对方的场景。

但是虽然没有本质区别,但是在使用习惯上还是存在一些差异。

  • GET请求通常会把要传给服务器的数据加到URL的 query、string 里面。
  • POST请求,经常把要传给服务器的数据加到body里面。 

这是习惯上最大的差别。当时上述情况并非绝对,GET也可以使用body,POST也可以使用  query、string ,使用的前提是客户端/服务器都得按照一样的方式来处理代码。 所以一般还是建议大家按照约定俗成的习惯,不要太特立独行~~~

语义不同:

  • GET一般用于获取数据,而POST一般用于提交数据。GET请求通常用于从服务器请求资源,而POST请求通常用于将数据提交到服务器,一般都是登录和上传
  • 相比之下,PUT和POST等,语义就比较混乱了。

数据传递方式:

  • GET请求的主体通常为空,需要传递的数据通过查询字符串(query string)传递,附加在URL上。
  • POST请求的查询字符串通常为空,需要传递的数据通过请求主体(body)传递,通常使用Content-Type头部指定数据格式。

幂等性:

  • 幂等是数学概念,即输入相同的内容,输出是稳定的。
  • GET请求一般是幂等的,即多次相同的GET请求应该返回相同的结果。
  • POST请求一般是不幂等的,如果多次相同的POST请求得到的结果一样,通常不视为请求是幂等的。
  • 但是需要注意,这种说法不够准确,但也不是完全出错。GET是否幂等不绝对,RFC上建议GET请求实现为幂等的。一个GET不幂等的情况:搜狗的广告搜索,这背后涉及到一系列复杂的逻辑操作。

缓存:

  • GET请求可以被缓存,因为它是幂等的,多次获取相同资源不会对服务器状态产生影响。
  • POST请求通常不被缓存,因为它通常用于对服务器状态进行更改。
  • 当然,这个说法也和上述幂等有关,是幂等性的延续,如果请求是幂等的,自然就可以缓存。

其他补充说明:

  • 关于语义:虽然GET和POST有常见的用途,但实际上,GET也可以用于提交数据,而POST也可以用于获取数据,因为HTTP本身并未强制这些语义。
  • 关于安全性:GET和POST在安全性方面并无绝对的不同,安全性主要取决于数据加密和其他安全措施的实施。
  • 关于传输数据量:HTTP标准未规定GET的URL或POST的主体的长度限制,因此传输数据量取决于浏览器和服务器的实现。
  • 关于传输数据类型:GET虽然不直接传输二进制数据,但可以对二进制数据进行URL编码以传输。

这里我们需要具体解释一下。

网络上经常有一些说法,需要注意:

1、GET请求能传递的数据量有上,POST没有。这个说法是一个历史遗留问题,早期版本的浏览器硬件资源非常匮乏,针对GET请求的URL长度做出了限制。但是实际上RFC标准文档中并没有明确规定URL能有多长,目前的浏览器和服务器的实现过程中,URL可以是非常长的,甚至可以使用URL传递一些图片这样的数据;

2、GET传递数据不安全,POST请求传递数据更安全。依据是:如果使用GET请求进行实现登陆,点击登陆的时候就会把用户名和密码放到URL中,进一步的显示到浏览器的地址栏里,相比之下POST则是在body中,不会在界面上显示出来,所以更安全。但是我们通常说的“安全”指的是传递的数据不容易被黑客获取,或者被获取到之后不容易被破解。所以此处的密码是加密的,即使拿到了也不容易破解。

3、GET只能给服务器传输文本数据,POST可以给服务器传输文本和二进制数据。

  • GET也不是不可以使用body,body中是可以直接放二进制的。
  • GET也可以把二进制数据进行base转码放到URL中的query和string中。

4、GET请求可以被浏览器收藏夹收藏,POST不能,因为收藏的时候可能会丢失body。这个说法目前是正确的,但是可能和技术关系不大,主要还是看你怎么提需求。 

我虽然提供了GET和POST方法之间的主要区别,但是具体的实现和应用还是得取决于浏览器和服务器的配置和要求。

HTTP其他方法

  1. PUT:

    • PUT方法用于向服务器上传、更新资源。与POST相似,但具有幂等特性,多次执行相同的PUT请求应该产生相同的结果。
    • 一般用于替换服务器上的资源。
  2. DELETE:

    • DELETE方法用于删除服务器上的指定资源。对服务器的状态产生更改。
  3. OPTIONS:

    • OPTIONS方法请求服务器返回所支持的HTTP请求方法,通常用于跨域请求中的预检请求(CORS预检请求)。
  4. HEAD:

    • HEAD方法类似于GET,但响应中不包含实体主体,只返回响应头信息。通常用于检索资源的元数据而不需要实际内容。
  5. TRACE:

    • TRACE方法用于回显服务器端接收到的请求,通常用于诊断和测试。对于安全性考虑,应该谨慎使用。
  6. CONNECT:

    • CONNECT方法是预留的,目前很少使用。通常用于建立代理服务器隧道,通常在HTTPS连接时使用。

我们提到这些HTTP方法可以使用Ajax或网络编程语言来构造,任何能进行网络编程的语言都可以构造HTTP请求,实质上就是通过TCP socket发送符合HTTP协议规则的字符串。

这些HTTP的请求最初的初心其实就是未来表示不同的语义。可是在现在的实际使用过程中,这个初心已经被遗忘了。HTTP的各种请求目前来说已经不一定完全遵守自己的规定了,你可以更加随意的使用。

HTTP请求详解

认识请求 "报头" (header)

请求头(header)是HTTP请求中的一部分,用于携带关于请求的元数据和其他信息。

HTTP请求头通常采用键值对的格式,每个键值对占一行,键和值之间使用冒号分隔(而不是分号)。

请求头提供了有关请求的重要信息,包括请求的方法、URL、主机、内容类型、身份验证凭证等等。

  1. GET /index.html HTTP/1.1
  2. Host: www.example.com
  3. User-Agent: Mozilla/5.0
  4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  5. Accept-Language: en-US,en;q=0.5
  6. Connection: keep-alive

在上面的示例中,每个键值对表示一个请求头,例如,"Host"头部指定了请求的主机名,"User-Agent"指定了发送请求的用户代理,"Accept"头部指定了接受的内容类型等等。

HTTP请求头是HTTP请求的一部分,它提供了关于请求的元数据信息,它们以键值对的格式表示,而不是使用分号分隔。

 报头的种类有很多, 此处我们仅介绍几个常见的。

1、Host:

定义与用途: 指定请求的服务器主机地址和端口。

示例: Host: www.example.com

这个信息在URL中也是存在的。但是在使用代理的情况下,Host的内容可能和URL中的内容不同。

2、Content-Length:

定义与用途: 指定请求主体或响应主体的数据长度,以字节为单位。

示例: Content-Length: 1234

非必须,请求里面有body才会有这个属性。通常情况下,GET请求里面就没有,POST就有。

TCP涉及到粘包问题,HTTP在传输层就是基于TCP的。使用同一个TCP连接,传输多个HTTP数据报,此时就会使多个GTTP数据包在TCP接收缓冲区中挨在一起。接收方解析的时候就需要能够清楚HTTP数据包之间的边界。

对于GET这种没有body的请求,直接使用空行作为分隔符;

对于POST这种有body的请求,就需要结合空行和Content-Length。

3、Content-Type:

  • 定义与用途: 指定请求或响应主体的数据格式,即body中数据的格式。
  • 常见选项和格式:
    • application/x-www-form-urlencoded:
      • 表单提交的标准数据格式。
      • 例如:key1=value1&key2=value2
    • multipart/form-data:
      • 通常用于表单提交,尤其是涉及到文件或图片上传。
      • 数据以边界(boundary)分隔。
      • 例如:
        1. Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
        2. ------WebKitFormBoundaryrGKCBY7qhFd3TrwA
        3. Content-Disposition: form-data; name="text"
        4. title
        5. ------WebKitFormBoundaryrGKCBY7qhFd3TrwA
        6. Content-Disposition: form-data; name="file"; filename="chrome.png"
        7. Content-Type: image/png
        8. ... content of chrome.png ...
        9. ------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
      • application/json:
        • 用于传输JSON格式的数据。
        • 例如:{"username":"123456789","password":"xxxx"}

非必须,请求里面有body才会有这个属性。通常情况下,GET请求里面就没有,POST就有。 

请求头部提供了关于请求内容和其他元数据的关键信息,帮助服务器正确解析和响应请求。

HTTP请求和响应的body中的格式可以有多种选择,取决于数据的类型和需求。以下是一些常见的HTTP请求和响应body中的格式:

HTTP请求body中的格式:

  1. JSON:常用于向服务器发送结构化的数据,如API请求。
  2. from表单的格式(相当于是把query string给搬到body中):通过application/x-www-form-urlencoded格式,通常用于HTML表单提交。
  3. 多部分表单数据,from=data的格式(上传文件的时候会涉及到,当然也不一定,也有可能是from表单,之前的上传图片就是,只是一个key一个value,但是这个value作为图片,非常大):通过multipart/form-data格式,常用于文件上传。
  4. XML:用于传输和接收XML格式的数据。
  5. 文本:纯文本数据,无格式。

HTTP响应body中的格式:

  1. HTML:通常用于呈现网页内容。
  2. JSON:用于API响应,传输结构化数据。
  3. 图像:如JPEG、PNG、GIF等,用于传输图像文件。
  4. CSS:用于定义页面样式。
  5. JavaScript:用于客户端执行脚本。
  6. XML:用于传输和接收XML格式的数据。
  7. 文本:纯文本数据,无格式。

后续给服务器提交给请求不同的 Content-Type ,服务器处理数据的逻辑也是不同的。服务器返回数据给浏览器们也需要设置合适的 Content-Type,浏览器也会根据不同的 Content-Type做出不同的处理。

其中响应中的HTML、CSS、JavaScript构成网页的主体,HTML表示页面的骨架,CSS表示页面的样式,JavaScript 表示页面的行为。

4、User-Agent(简称 UA)

定义与用途:表示发送请求的用户代理的属性,通常是浏览器或其他客户端应用。描述里你使用什么设备上网。

格式与内容:

UA字符串通常包含操作系统、硬件类型、浏览器以及浏览器的渲染引擎等信息。

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36

Windows NT 10.0; Win64; x64 表示操作系统版本信息。

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 表示浏览器版本和其使用的渲染引擎信息。

背景与历史:

  • User-Agent(UA)字符串的格式和内容常常受到历史遗留问题的影响。在互联网的早期,网站的内容相对简单,而浏览器之间的差异也很大。为了提供最佳的用户体验,网站开发者需要考虑到多个浏览器版本的兼容性。

  • 随着时间的推移,网页的内容变得越来越丰富,浏览器更新和升级的速度也加快了。这导致了新旧版本浏览器的并存,因此,开发者既要考虑到老版本浏览器的兼容性,又要确保新版本浏览器用户的体验得到保障。为了解决这个问题,开发者开始使用UA来识别并区分不同的浏览器。UA中记录了浏览器的版本、所支持的特性等信息,这为开发者提供了巨大的帮助。

  • 然而,随着各大浏览器厂商争夺市场份额,为了确保网站能够在其浏览器上正确显示,浏览器开始在UA字符串中包含其他浏览器的标识。这导致了UA字符串变得越来越复杂和冗长。

  • 现代互联网的发展已经使得大多数浏览器之间的差异变得很小。现在的前端开发技术,如“响应式网页”编程,使得同一个HTML页面能够很好地适应不同的设备和浏览器。因此,UA的重要性已经大大降低,现在它主要被用来识别是PC端还是移动端。
  • 由于这种标识的历史原因,现代浏览器的 User-Agent  字符串包含了大量的信息,这有时会导致隐私和安全问题。因此,有一些提议和措施正在考虑修改或简化 User-Agent  字段的内容,以提高用户隐私。
  • 现在浏览器的差异已经很小了,此时UA的作用也就没有那么关键了。现在UA主要是用来区分是PC端还是移动端。这样的区分一般只是为了进行统计,而不会返回不同版本的页面。现在前端开发有“响应式网页”编程技术,同一个HTML很好的兼容不同的设备。

总之,User-Agent  请求头部字段提供了关于请求来源的用户代理的详细信息,这有助于服务器为不同的设备、操作系统或浏览器提供适当的响应。

5、Referer

定义与用途:

  • Referer表示当前请求的来源页面(是从哪里跳转来的),即引导用户前往当前页面的页面的URL。
  • 它用于记录用户从哪个页面跳转到当前页面,以帮助网站分析流量和用户导航。
  • 当用户直接在浏览器地址栏中输入URL或者通过点击书签/收藏夹中的链接来访问网页时,通常不会发送Referer头部字段。这是因为Referer字段是由上一个页面传递给当前页面的,但在这种情况下,没有上一个页面。因此,浏览器不会发送Referer信息。

    Referer字段通常用于标识从哪个页面跳转过来,以便网站或服务器了解用户的访问来源。但在直接输入URL或使用书签的情况下,没有上一个页面可供标识,因此没有Referer信息发送到目标网页。

  • 用户点击广告之后,广告平台每次跳转之前都会先跳转到一个计费服务器,再跳转到广告主的页面。广告主通过记录日志就知道点击情况了。

  • 广告主也可能会在很多不同的平台投放广告,广告主的服务器就需要区分出哪些请求是来自A,哪些请求又是来自B?我们通过Referer就可以进行区分(域名不同)

  • 是否会存在一种情况?有人把Referer给改了,本来是“搜狗”的广告,结果跳转到了别的广告平台?在早期的互联网中,确实存在运营商或中间人劫持的情况,其中修改HTTP请求或响应中的信息,如Referer,是其中的一种手法。这种行为通常是为了注入广告或跟踪用户活动,甚至可能用于监视和搜集用户的数据。因为网络数据都是通过运营商的设备(路由器/交换机)转发的,运营商通过在路由器上部署一些特定的程序,就很容易能够获取到,也就很容易篡改。所以后面就使用HTTTPS来替代HTTP,HTTP最大的问题在于“明文传输”,这就容易被第三方获取并篡改。而HTTPS对HTTP的数据进行了加密,第三方想要获取并篡改就没那么容易了,通过这个手段就可以有效地遏制运营商劫持。

  • HTTPS的广泛采用是一个重要的改进,因为它通过加密通信来保护数据的完整性和隐私,使运营商或其他恶意第三方更难以篡改用户的数据。HTTPS的加密机制通过使用SSL/TLS协议来实现,确保了数据在传输过程中的保密性。

    运营商劫持等恶意行为在HTTPS广泛采用后变得更加困难,因为HTTPS通信中的数据在客户端和服务器之间进行端到端的加密,防止了中间人的干预。此外,Web浏览器和网站也会检测证书,以确保与服务器建立安全的HTTPS连接。

    尽管HTTPS提供了更高的安全性,但仍然可能存在一些其他安全漏洞和攻击,例如钓鱼攻击、恶意证书颁发等。因此,大家都需要保持警惕,并确保采取适当的安全措施,以降低潜在威胁的风险。同时,不断更新和改进网络协议和安全措施也是网络安全的一部分。

示例:

  • Referer: https://www.example.com/previous-page

注意:

  • 如果用户直接在浏览器中输入URL、使用收藏夹访问页面,或者通过其他方式访问页面而没有从其他页面跳转过来,Referer字段可能为空或缺失。

6、 Cookie

定义与用途:

  • Cookie 字段用于在HTTP请求和响应之间存储和传递数据,可以被认为是浏览器在本地存储数据的一种机制。
  • 浏览器的数据来自于服务器,浏览器后续的操作也是要提交给服务器的。服务器这边管理了一个网站的核心数据。但程序运行过程中也会有一些数据需要在浏览器这里储存,并且在后续请求的时候数据可能需要再发给服务器,比如上次登录的时间、上次访问的时间、用户的身份信息、累积的访问次数……这些临时性的数据存储在浏览器中是比较合适的。
  • 实际上我们更容易想到的方法是把这样的数据直接存储到本地文件中。但是实际上是不可行的。浏览器为了考虑安全性,禁止网页直接访问你的电脑的文件系统(病毒杀毒),网页代码也就无法直接生成一个硬盘的文件来存储数据了。
  • 为了保证安全性,又能进行存储数据,于是就引入了Cookie,也是按照硬盘文件的方式保存的,但是浏览器把操作文件给封装了,网页只能往Cookie里面存储键值对,也就是一些简单的字符串。
  • Cookie是一种用于在客户端(通常是浏览器)和服务器之间存储小段数据的机制。这些数据以键值对的形式存储,通常是程序员自己定义的。这些键值对可以包含一些简单的字符串,通常用于存储用户会话信息、首选项、身份验证令牌等。
  • 数据通常以键值对的形式存储在Cookie中的,这里的键值对是程序猿自己定义的(和 query string 类似)
  • Cookie往往是从服务器返回的数据,可以由服务器返回给客户端,也可以由页面的JavaScript代码自己生成并存储在客户端。服务器通常在HTTP响应头中设置Cookie,而浏览器会将它们存储在客户端的硬盘上。客户端的JavaScript代码可以通过浏览器的Document对象来创建、读取和修改Cookie。
  • Cookie存储到浏览器所在主机的硬盘上,并且是按照域名的维度来存储的,每个域名可以在客户端存储自己的Cookie数据,这些Cookie是与特定域名关联的。不同域名之间的Cookie通常是相互隔离的,它们不会互相访问或共享数据。
  • 当浏览器再次请求同一服务器时,它会自动将相关Cookie包含在HTTP请求的Cookie头中,发给服务器,服务器可以读取这些Cookie,就会通过Cookie的内容做一些逻辑上的处理,例如身份验证或用户会话跟踪。
  • 总的来说就是:Cookie保存了一些给程序员使用的数据。

示例:

  • Cookie: username=johndoe; sessionid=123456
  • 键值对之间使用 ;分割,键和值使用 = 分割。
  • 这些内容就是浏览器本地存储的Cookie,都会在后续请求服务器的时候把这些内容自动代入到请求中,发给服务器,服务器就通过Cookie的内容做一些逻辑上的处理。

关于域名和Cookie:

  • 每个不同的域名(网站)可以有自己的Cookie,这些Cookie在不同网站之间不会冲突。
  • 通过HTTP响应的Set-Cookie头部字段,服务器可以向浏览器设置Cookie数据。

Referer和Cookie是HTTP请求头部字段的一部分,它们提供了在Web应用程序中进行跟踪和标识的功能,用于了解用户行为和提供个性化服务。

前期准备

通过抓包观察网页登录过程是一种常见的方式来了解网络通信和验证身份的过程。以下是一般的步骤,以观察码云登录过程为例:

  1. 安装抓包工具:

    • 首先,你需要安装一个网络抓包工具。一些常见的抓包工具包括Fiddler、Wireshark、Charles等,你可以根据你的需求和操作系统选择一个合适的工具。
  2. 启动抓包工具:

    • 启动你选择的抓包工具,并设置它以侦听本地网络流量。
  3. 清除浏览器中的Cookie:

    • 打开你的浏览器,登录到码云账户(或你要观察的目标网站)。
    • 在浏览器中,清除之前存在的Cookie。这通常可以在浏览器的设置或开发者工具中找到。你可以通过清除浏览器的Cookie来模拟"未登录"状态,以便观察登录过程。
  4. 进行登录:

    • 在浏览器中,输入你的用户名和密码并尝试登录到码云(或目标网站)。
  5. 观察抓包工具:

    • 回到抓包工具,你应该能够看到登录请求和响应的细节,包括HTTP头部信息和Cookie。
  6. 查看登录请求和响应:

    • 查看抓包工具中的请求和响应数据。你应该能够看到包含用户名和密码的POST请求,以及来自服务器的响应,可能包括登录凭据的Cookie。
  7. 分析数据:

    • 通过分析这些数据,你可以了解登录过程的细节,包括请求头部、POST数据、响应头部和Cookie的使用。

这个过程允许你深入了解网站登录的内部工作原理,并可以帮助你识别如何实施身份验证和会话管理等功能。请注意,进行网络抓包时,请遵守相关法律和道德规范,不要滥用这些信息。

登陆操作

登陆请求

  1. POST https://gitee.com/login HTTP/1.1
  2. Host: gitee.com
  3. Connection: keep-alive
  4. Content-Length: 394
  5. Cache-Control: max-age=0
  6. sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  7. sec-ch-ua-mobile: ?0
  8. Upgrade-Insecure-Requests: 1
  9. Origin: https://gitee.com
  10. Content-Type: application/x-www-form-urlencoded
  11. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  12. like Gecko) Chrome/91.0.4472.101 Safari/537.36
  13. Accept:
  14. text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
  15. e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  16. Sec-Fetch-Site: same-origin
  17. Sec-Fetch-Mode: navigate
  18. Sec-Fetch-User: ?1
  19. Sec-Fetch-Dest: document
  20. Referer: https://gitee.com/login
  21. Accept-Encoding: gzip, deflate, br
  22. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  23. encrypt_key=password&utf8=%E2%9C%93&authenticity_token=36ZqO9tglSN6EB6pF6f2Gt%2B
  24. dalgkbpTDUsJC5OER7w8%3D&redirect_to_url=%2FHGtz2222&user%5Blogin%5D=HGtz2222&enc
  25. rypt_data%5Buser%5Bpassword%5D%5D=Hy2gjJ60312Ss12jSe21GMLPEb766tAhCygL281FLRMpiz
  26. xJVaWGOPlQF7lZhelab1HS2vBiwfBo5C7BnR5ospoBiK1hR6jNXv1lesaYifv9dP1iRC6ozLLMszo%2F
  27. aRh5j5DeYRyKcE0QJjXRGEDg4emXEK1LHVY4M1uqzFS0W58%3D&user%5Bremember_me%5D=0

这是一个示例的登录请求,采用POST方法,发送到https://gitee.com/login。以下是请求头的详细解释,按照你之前提供的格式:

登录请求头部
  1. 请求方法和URL:

    • 请求方法:POST
    • URL:https://gitee.com/login
  2. Host:

    • 表示服务器主机的地址和端口。
    • 示例:Host: gitee.com
  3. Connection:

    • 指定连接选项,此处为保持连接。
    • 示例:Connection: keep-alive
  4. Content-Length:

    • 表示请求主体(body)的长度,以字节为单位。
    • 示例:Content-Length: 394
  5. Cache-Control:

    • 控制缓存行为的指令。
    • 示例:Cache-Control: max-age=0
  6. User-Agent:

    • 表示用户代理(浏览器和操作系统)的属性。
    • 示例:User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36
  7. Accept:

    • 指定客户端可接受的内容类型。
    • 示例:Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  8. Content-Type:

    • 指定请求主体的数据格式,此处为application/x-www-form-urlencoded,表示表单数据。
    • 示例:Content-Type: application/x-www-form-urlencoded
  9. Referer:

    • 表示请求的来源页面的URL,通常是登录页面。
    • 示例:Referer: https://gitee.com/login
  10. Accept-Encoding:

    • 指定客户端可接受的内容编码。
    • 示例:Accept-Encoding: gzip, deflate, br
  11. Accept-Language:

    • 指定客户端接受的语言。
    • 示例:Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  12. 请求主体 (Body):

    • 请求主体包含用户的登录信息,通常以键值对的形式传递,如encrypt_key=passworduser[login]=HGtz2222等。

这个请求头部用于将登录信息发送到https://gitee.com/login,以进行用户身份验证。服务器将使用请求主体中的数据来验证用户并进行相应的操作。请注意,登录请求通常包含用户名和密码等敏感信息,应该使用安全的HTTPS连接来保护这些数据的传输。

 登陆响应

  1. HTTP/1.1 302 Found
  2. Date: Thu, 10 Jun 2021 04:15:58 GMT
  3. Content-Type: text/html; charset=utf-8
  4. Connection: keep-alive
  5. Keep-Alive: timeout=60
  6. Server: nginx
  7. X-XSS-Protection: 1; mode=block
  8. X-Content-Type-Options: nosniff
  9. X-UA-Compatible: chrome=1
  10. Expires: Sun, 1 Jan 2000 01:00:00 GMT
  11. Pragma: must-revalidate, no-cache, private
  12. Location: https://gitee.com/HGtz2222
  13. Cache-Control: no-cache
  14. Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041 04:16:00
  15. -0000
  16. Set-Cookie: gitee_user=true; path=/
  17. Set-Cookie: gitee-sessionn=M1Rhbk1QUUxQdWk1VEZVQ1BvZXYybG13ZUJFNGR1V0pSYTZyTllEa21pVHlBUE5QU2Qwdk44NXdEam
  18. 11T3FZYXFidGNYaFJxcTVDRE1xU05GUXN0ek1Uc08reXRTay9ueTV3OGl5bTdzVGJjU1lUbTJ4bTUvN1
  19. l3RFl4N2hNQmI1SEZpdmVJWStETlJrdWtyU0lDckhvSGJHc3NEZDFWdHc5cjdHaGVtNThNcEVOeFZlaH
  20. c0WVY5NGUzWjc2cjdOcCtSdVJ0VndzdVNxb3dHK1hPSDBDSFB6WlZDc3prUVZ2RVJyTnpTb1c4aFg1Mm
  21. UxM1YvQTFkb1EwaU4zT3hJcmRrS3dxVFZJNXoxaVJwa1liMlplbWR5QXQxY0lvUDNic1hxN2o0WDg1Wk
  22. E9LS10N0VIYXg4Vm5xdllHVzdxa0VlUEp3PT0%3D-
  23. -2f6a24f8d33929fe88ed19d4dea495fbb40ebed6; domain=.gitee.com; path=/; HttpOnly
  24. X-Request-Id: 77f12d095edc98fab27d040a861f63b1
  25. X-Runtime: 0.166621
  26. Content-Length: 92
  27. <html><body>You are being <a href="https://gitee.com/HGtz2222">redirected</a>.
  28. </body></html>

这是一个示例的登录响应,HTTP响应代码为302 Found,表示重定向。

可以看到, 响应中包含了 3 个 Set-Cookie 属性. 其中我们重点关注第三个. 里面包含了一个 gitee-session-n 这样的属性, 属性值是一串很长的加 密之后的信息。这个信息就是用户当前登陆的身份标识. 也称为 "令牌(token)"

以下是响应头和主体的详细解释:

登录响应头部
  1. HTTP版本和状态码:

    • HTTP版本:HTTP/1.1
    • 状态码:302 Found
  2. Date:

    • 指定响应的日期和时间。
    • 示例:Date: Thu, 10 Jun 2021 04:15:58 GMT
  3. Content-Type:

    • 指定响应主体的内容类型。
    • 示例:Content-Type: text/html; charset=utf-8
  4. Connection:

    • 指定连接选项,此处为保持连接。
    • 示例:Connection: keep-alive
  5. Keep-Alive:

    • 指定保持连接的超时时间。
    • 示例:Keep-Alive: timeout=60
  6. Server:

    • 指定服务器名称和版本信息。
    • 示例:Server: nginx
  7. X-XSS-Protection:

    • 启用或禁用浏览器的跨站脚本攻击保护。
    • 示例:X-XSS-Protection: 1; mode=block
  8. X-Content-Type-Options:

    • 指定浏览器是否应该嗅探响应中的内容类型。
    • 示例:X-Content-Type-Options: nosniff
  9. X-UA-Compatible:

    • 指定浏览器的兼容性模式。
    • 示例:X-UA-Compatible: chrome=1
  10. Expires:

    • 指定响应的过期时间。
    • 示例:Expires: Sun, 1 Jan 2000 01:00:00 GMT
  11. Pragma:

    • 指定缓存策略,如必须重新验证、不缓存等。
    • 示例:Pragma: must-revalidate, no-cache, private
  12. Location:

    • 重定向的目标URL,表示登录成功后用户将被重定向到https://gitee.com/HGtz2222
    • 示例:Location: https://gitee.com/HGtz2222
  13. Cache-Control:

    • 控制缓存行为的指令,此处指示不缓存。
    • 示例:Cache-Control: no-cache
  14. Set-Cookie:

    • 设置Cookie,其中包括oschina_new_usergitee_user等Cookie。
    • 示例:
      1. Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041 04:16:00 -0000
      2. Set-Cookie: gitee_user=true; path=/
      3. Set-Cookie: ...
  15. X-Request-Id:

    • 响应中的请求ID。
    • 示例:X-Request-Id: 77f12d095edc98fab27d040a861f63b1
  16. X-Runtime:

    • 服务器处理请求的运行时间。
    • 示例:X-Runtime: 0.166621
响应主体

响应主体是一个HTML文档,包含了重定向消息,告诉用户他们将被重定向到https://gitee.com/HGtz2222。这是一个常见的登录成功后的操作,用户将被重定向到他们的个人页面或其他受保护的区域。

这个响应表明登录成功,并且用户的身份验证状态已更新,将被重定向到新的URL。登录后,用户的身份将由gitee_user Cookie来维护,这个Cookie将在登录成功后的响应头中设置。

重定向是常见的用户身份验证操作之一,它允许用户成功登录后被自动导航到他们的目标页面,以提供良好的用户体验。

访问其他页面

登陆成功之后, 此时可以看到后续访问码云的其他页面(比如个人主页), 请求中就都会带着刚才获取到的 Cookie 信息

  1. GET https://gitee.com/HGtz2222 HTTP/1.1
  2. Host: gitee.com
  3. Connection: keep-alive
  4. Cache-Control: max-age=0
  5. Upgrade-Insecure-Requests: 1
  6. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  7. like Gecko) Chrome/91.0.4472.101 Safari/537.36
  8. Accept:
  9. text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
  10. e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  11. Sec-Fetch-Site: same-origin
  12. Sec-Fetch-Mode: navigate
  13. Sec-Fetch-User: ?1
  14. Sec-Fetch-Dest: document
  15. sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  16. sec-ch-ua-mobile: ?0
  17. Referer: https://gitee.com/login
  18. Accept-Encoding: gzip, deflate, br
  19. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  20. Cookie: oschina_new_user=false; user_locale=zh-CN; yp_riddler_id=1ce4a551-a160-
  21. 4358-aa73-472762c79dc0; visit-gitee--2021-05-06%2010%3A12%3A24%20%2B0800=1;
  22. sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%22726826%22%2C%22first_id%22%3
  23. A%22175869ba5888b6-0ea2311dc53295-303464-2073600-
  24. 175869ba5899ac%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E
  25. 7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_search_keyword%22%3A%22%E6%
  26. 9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%2
  27. 4latest_referrer%22%3A%22%22%7D%2C%22%24device_id%22%3A%22175869ba5888b6-
  28. 0ea2311dc53295-303464-2073600-175869ba5899ac%22%7D; remote_way=svn;
  29. tz=Asia%2FShanghai;
  30. Hm_lvt_24f17767262929947cc3631f99bfd274=1622637014,1622712683,1622863899,1623298
  31. 442; Hm_lpvt_24f17767262929947cc3631f99bfd274=1623298550; gitee_user=true; giteesessionn=M1Rhbk1QUUxQdWk1VEZVQ1BvZXYybG13ZUJFNGR1V0pSYTZyTllEa21pVHlBUE5QU2Qwdk44NXdEam
  32. 11T3FZYXFidGNYaFJxcTVDRE1xU05GUXN0ek1Uc08reXRTay9ueTV3OGl5bTdzVGJjU1lUbTJ4bTUvN1
  33. l3RFl4N2hNQmI1SEZpdmVJWStETlJrdWtyU0lDckhvSGJHc3NEZDFWdHc5cjdHaGVtNThNcEVOeFZlaH
  34. c0WVY5NGUzWjc2cjdOcCtSdVJ0VndzdVNxb3dHK1hPSDBDSFB6WlZDc3prUVZ2RVJyTnpTb1c4aFg1Mm
  35. UxM1YvQTFkb1EwaU4zT3hJcmRrS3dxVFZJNXoxaVJwa1liMlplbWR5QXQxY0lvUDNic1hxN2o0WDg1Wk
  36. E9LS10N0VIYXg4Vm5xdllHVzdxa0VlUEp3PT0%3D-
  37. -2f6a24f8d33929fe88ed19d4dea495fbb40ebed6

这是一个示例的GET请求,用于访问 https://gitee.com/HGtz2222 登陆成功之后的页面。以下是请求头的详细解释,:

GET请求头部

  1. 请求方法和URL:

    • 请求方法:GET
    • URL:https://gitee.com/HGtz2222
  2. Host:

    • 表示服务器主机的地址和端口。
    • 示例:Host: gitee.com
  3. Connection:

    • 表示连接方式,这里是保持连接。
    • 示例:Connection: keep-alive
  4. Cache-Control:

    • 控制缓存的行为,这里是不使用缓存。
    • 示例:Cache-Control: max-age=0
  5. Upgrade-Insecure-Requests:

    • 表示是否允许不安全的请求升级为安全的请求。
    • 示例:Upgrade-Insecure-Requests: 1
  6. User-Agent:

    • 表示浏览器和操作系统的属性,用于标识客户端。
    • 示例:User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36
  7. Accept:

    • 表示客户端可以接受的媒体类型。
    • 示例:Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  8. Sec-Fetch-Site:

    • 表示请求目标的站点类型,这里是"same-origin",表示同源请求。
    • 示例:Sec-Fetch-Site: same-origin
  9. Sec-Fetch-Mode:

    • 表示请求模式,这里是"navigate",表示导航请求。
    • 示例:Sec-Fetch-Mode: navigate
  10. Sec-Fetch-User:

    • 表示请求用户,这里是"?1",表示请求用户已经存在。
    • 示例:Sec-Fetch-User: ?1
  11. Sec-Fetch-Dest:

    • 表示请求目标的类型,这里是"document",表示文档请求。
    • 示例:Sec-Fetch-Dest: document
  12. sec-ch-ua:

    • 表示浏览器和操作系统的属性。
    • 示例:sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  13. sec-ch-ua-mobile:

    • 表示浏览器在移动设备上的属性。
    • 示例:sec-ch-ua-mobile: ?0
  14. Referer:

    • 表示请求是从哪个页面跳转过来的。
    • 示例:Referer: https://gitee.com/login
  15. Accept-Encoding:

    • 表示客户端可以接受的编码方式,例如gzip、deflate等。
    • 示例:Accept-Encoding: gzip, deflate, br
  16. Accept-Language:

    • 表示客户端的语言偏好。
    • 示例:Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  17. Cookie:

    • 表示之前获取到的Cookie信息,用于在服务器端识别用户。
    • 示例:包含多个Cookie键值对,如Cookie: oschina_new_user=false; user_locale=zh-CN; ...

这个GET请求包含了之前登录成功后获取的Cookie信息,用于访问个人主页

请求你中的 Cookie 字段也包含了一个 gitee-session-n 属性, 里面的值和刚才服务器返回的值相 同。 后续只要访问 gitee 这个网站, 就会一直带着这个令牌, 直到令牌过期/下次重新登陆。

理解登陆过程

这个过程和去医院看病很相似: 

  1. 到医院挂号:

    • 在网站上,这相当于首次访问网站并填写登录信息(如用户名和密码)。
    • 提供身份证等于提供你的用户名和密码。
    • 得到“就诊卡”相当于从服务器收到一个用于后续识别的令牌或Cookie。
  2. 后续去各个科室:

    • 当你浏览一个登录后才能访问的页面或进行其他操作时,你不需要再次输入用户名和密码。这是因为你的浏览器会自动发送那个令牌或Cookie,告诉服务器你是谁。
    • 这就像用就诊卡来证明自己的身份,而不是每次都出示身份证。
  3. 看完病后注销就诊卡:

    • 在网站上,这类似于点击“注销”或“退出登录”按钮。这通常会使当前的令牌或Cookie失效,这样即使其他人得到了它也不能用它来伪装成你。
    • 如果你的就诊卡丢了,它不会泄露你的身份证信息,因为它只是一个令牌,不包含敏感信息。
  4. 再次来医院看病:

    • 如果你想再次访问受限制的内容,你需要重新登录,这时服务器会为你生成一个新的令牌或Cookie。
    • 这就像每次去医院时都需要重新办理一个新的就诊卡。

通过这个比喻,我们可以更容易地理解身份验证的原理,以及令牌和Cookie在其中的作用。这也强调了为什么在使用完后应该注销令牌或Cookie,以保护自己的账户安全。

 认识请求 "正文" (body)

正文中的内容格式和 header 中的 Content-Type 密切相关。 上面也罗列了三种常见的情况。

HTTP请求正文(Request Body)是HTTP请求的一部分,它包含了客户端发送给服务器的数据或内容。请求正文的内容格式通常与请求头中的Content-Type字段密切相关,Content-Type字段指定了请求正文的数据类型和格式。

以下是几种常见的请求正文示例,每种示例与不同的Content-Type相关:

1、application/x-www-form-urlencoded:这是一种常见的请求正文格式,通常用于HTML表单提交。数据以键值对的形式编码,并以application/x-www-form-urlencoded格式发送给服务器。示例:

  1. Content-Type: application/x-www-form-urlencoded
  2. user=username&password=pass123

这个请求正文包含了用户的用户名和密码。

2、application/json:JSON格式的请求正文通常用于通过JSON对象发送数据给服务器。示例:

  1. Content-Type: application/json
  2. {
  3.   "name": "John",
  4.   "age": 30,
  5.   "city": "New York"
  6. }

这个请求正文包含了一个JSON对象,描述了用户的名称、年龄和所在城市。

3、multipart/form-data:这种格式通常用于文件上传,允许在请求正文中包含文件数据。示例:

  1. Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
  2. Content-Disposition: form-data; name="file"; filename="example.jpg"
  3. Content-Type: image/jpeg
  4. (binary data for the file)

这个请求正文包含了一个文件,文件名为"example.jpg"。

HTTP请求正文的内容可以根据应用程序的需求和HTTP请求的目的而有所不同。Content-Type字段用于指定请求正文的数据类型和编码方式,以确保服务器能够正确解释和处理请求的内容。服务器会根据Content-Type的值来解析请求正文,并采取相应的操作,无论是提交表单数据、JSON对象,还是上传文件。

下面可以通过抓包来观察这几种情况:

(1)application/x-www-form-urlencoded,抓取码云上传头像请求

  1. POST https://gitee.com/profile/upload_portrait_with_base64 HTTP/1.1
  2. Host: gitee.com
  3. Connection: keep-alive
  4. Content-Length: 107389
  5. sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  6. Accept: */*
  7. X-CSRF-Token: 6ROfZGr4Y7Qx8td1TuKCnrG8gbODLCSUqUBZSw2b+ac=
  8. X-Requested-With: XMLHttpRequest
  9. sec-ch-ua-mobile: ?0
  10. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  11. like Gecko) Chrome/91.0.4472.101 Safari/537.36
  12. Content-Type: application/x-www-form-urlencoded; charset=UTF-8
  13. Origin: https://gitee.com
  14. Sec-Fetch-Site: same-origin
  15. Sec-Fetch-Mode: cors
  16. Sec-Fetch-Dest: empty
  17. Referer: https://gitee.com/HGtz2222
  18. Accept-Encoding: gzip, deflate, br
  19. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  20. Cookie: oschina_new_user=false; user_locale=zh-CN; yp_riddler_id=1ce4a551-a160-
  21. 4358-aa73-472762c79dc0; visit-gitee--2021-05-06%2010%3A12%3A24%20%2B0800=1;
  22. sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%22726826%22%2C%22first_id%22%3
  23. A%22175869ba5888b6-0ea2311dc53295-303464-2073600-
  24. 175869ba5899ac%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E
  25. 7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_search_keyword%22%3A%22%E6%
  26. 9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%2
  27. 4latest_referrer%22%3A%22%22%7D%2C%22%24device_id%22%3A%22175869ba5888b6-
  28. 0ea2311dc53295-303464-2073600-175869ba5899ac%22%7D; remote_way=svn;
  29. tz=Asia%2FShanghai;
  30. Hm_lvt_24f17767262929947cc3631f99bfd274=1622637014,1622712683,1622863899,1623298
  31. 442; gitee_user=true; Hm_lpvt_24f17767262929947cc3631f99bfd274=1623298560; giteesessionn=c0hXQ0I5SjR1bWg5M01IR3RYS3hLT0RhelN1aFVuMExKdEdSSmRaQWIwRy9QWFUwV0thdzV1alIzYj
  32. RaOU9ZeDdkZEJZK2RtTVRNeTNFRHNYVW9ha2hEcWJyclIwS1NVRG1EL0xxTmJXSGxvSzh3c28zOHBia1
  33. pIOFQrU3RYeWE0bE13S09DTm5MZWZ5WW5WUVFpSzFiMGFWbHRDQ0xRakc1Um5yY21HQllqeUpNLzBvZF
  34. gxbHVhN09uK2h1VVVmRHZkS3BmVGEwcDhyNjJVb1p0RFRLY0VOem5vNEEvd0FuYzJJYlhZcGlyenZQc3
  35. dSbXBNUWI3UUwrRDBrV2N0UHZRdjFBUXF5b0Y0L1Vrd09pQVBKNkdjZmY5cHlDTCtMWG4ya0tIaW5LcE
  36. tBTkw4cGFGVjhUQ0djMWhkOXI0bUFteUY4VW80RHl2T2Q2YmxwR1d3M3Rad1RhZWhhdnNiTTNrcE1RV2
  37. NyZ1dYeDRoR0dpanh4bERNMTBuenB1NkgxLS16QUdJS3NlZG9mTVBtYlVlREppck1BPT0%3D-
  38. -898d1284181ca494918d29ac44f9a3a79d448a9b
  39. avatar=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAAPgAAAD4CAYAAADB0Ss
  40. LAAAg......

实际的抓包结果比较长, 此处没有全部贴出。

这是一个通过POST请求上传用户头像的示例。让我们来分析一下这个请求:

  1. 请求方法:这是一个HTTP POST请求。

  2. 请求目标:请求的URL是https://gitee.com/profile/upload_portrait_with_base64 

  3. 请求头部:

    • Host: gitee.com 是请求的主机名。
    • Connection: keep-alive 表示要保持长连接。
    • Content-Length: 107389 表示请求正文的长度为107389字节。
    • sec-ch-ua, Accept, X-CSRF-Token, X-Requested-With, sec-ch-ua-mobile, User-Agent, Content-Type, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段,它们包含了与请求相关的各种信息,包括用户代理信息(User-Agent),请求的来源(Referer),Cookie等。
  4. 请求正文(Body):

    • 这是一个表单形式(application/x-www-form-urlencoded)的请求。请求正文中包含了用户头像的数据。
    • avatar=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAAPgAAAD4CAYAAADB0SsLAAAg... 是头像数据的一部分。这部分可能包含了用户头像的图像数据,以Base64编码的方式表示。

这个请求的主要目的是将用户头像数据上传到指定的URL。请求头中包含了一些与请求相关的信息,包括用户代理(User-Agent)、来源(Referer)、Cookie等。请求正文中包含了头像数据,可以由服务器来解析和处理。

(2)multipart/form-data 抓取系统的 "上传简历" 功能:

  1. POST https://v.bitedu.vip/tms/oss/upload/file HTTP/1.1
  2. Host: v.CSDN.vip
  3. Connection: keep-alive
  4. Content-Length: 293252
  5. sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  6. Authorization: Bearer
  7. eyJhbGciOiJIUzUxMiJ9.eyJsb2dpbl91c2VyX2tleSI6IjFiYThjMDM5LWUyN2UtNDdhZS04YTAzLTN
  8. mNWMzY2UwN2YyNSJ9.VQWoqrrgWZpDNc81tYfSvna8A9uZP6QKqucnvGMuY8wbavHF30rx7NG9VxnAo1
  9. 78V0nOJBd75QxRvNRgpY6-Iw
  10. sec-ch-ua-mobile: ?0
  11. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  12. like Gecko) Chrome/91.0.4472.101 Safari/537.36
  13. Content-Type: multipart/form-data; boundary=----
  14. WebKitFormBoundary8d5Rp4eJgrUSS3wT
  15. Accept: */*
  16. Origin: https://v.bitedu.vip
  17. Sec-Fetch-Site: same-origin
  18. Sec-Fetch-Mode: cors
  19. Sec-Fetch-Dest: empty
  20. Referer: https://v.baidu.vip/personInf/student?userId=634
  21. Accept-Encoding: gzip, deflate, br
  22. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  23. Cookie: rememberMe=true; username=2342412223; AdminToken=eyJhbGciOiJIUzUxMiJ9.eyJsb2dpbleSI6IjFiYThjMDM5LWUyN2UtNDdhZS04Y
  24. TAzLTNmNWMzY2UwN2YyNSJ9.VQWoqrrgWZpDNc81tYfSvna8A9uZP6QKqucnvGMuY8wbavHF30rx7NG9
  25. VxnAo178V0nOJBd75QxRvNRgpY6-Iw
  26. ------WebKitFormBoundary8d5Rp4eJgrUSS3wT
  27. Content-Disposition: form-data; name="file"; filename="李星亚 Java开发工程师.pdf"
  28. Content-Type: application/pdf
  29. %PDF-1.7
  30. 1 0 obj
  31. <</Names <</Dests 4 0 R>> /Outlines 5 0 R /Pages 2 0 R /Type /Catalog>>
  32. endobj
  33. 3 0 obj
  34. <</Author ( N v~N•) /Comments () /Company () /CreationDate
  35. (D:20201122145133+06'51') /Creator ( W P S e [W) /Keywords () /ModDate
  36. (D:20201122145133+06'51') /Producer () /SourceModified (D:20201122145133+06'51')
  37. /Subject () /Title () /Trapped /False>>
  38. endobj
  39. 13 0 obj
  40. <</AIS false /BM /Normal /CA 1 /Type /ExtGState /ca 1>>
  41. endobj

实际的抓包结果比较长, 此处没有全部贴出。

这是一个通过POST请求上传文件的示例,使用的是multipart/form-data格式。让我来分析这个请求:

  1. 请求方法:这是一个HTTP POST请求。

  2. 请求目标:请求的URL是https://v.CSDN.vip/tms/oss/upload/file。 

  3. 请求头部:

    • Host: v.CSDN.vip 是请求的主机名。
    • Connection: keep-alive 表示要保持长连接。
    • Content-Length: 293252 表示请求正文的长度为293252字节。
    • sec-ch-ua, Authorization, sec-ch-ua-mobile, User-Agent, Content-Type, Accept, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段,它们包含了与请求相关的各种信息,包括用户代理信息(User-Agent)、授权信息(Authorization)、请求的来源(Referer)、Cookie等。
  4. 请求正文(Body):

    • 这是一个multipart/form-data格式的请求。请求正文以------WebKitFormBoundary8d5Rp4eJgrUSS3wT开始,然后包含了文件数据。
    • Content-Disposition 字段中的name属性表示字段的名称,filename属性表示上传文件的原始文件名。
    • Content-Type 字段表示上传的文件类型为application/pdf,PDF文件。
    • 接下来是文件内容,这里显示了PDF文件的一些内容。

这个请求的主要目的是将一个文件上传到指定的URL,文件的名称是"李星亚 Java开发工程师.pdf",文件类型为PDF。请求头中包含了一些与请求相关的信息,包括用户代理(User-Agent)、授权信息(Authorization)、来源(Referer)、Cookie等。请求正文以multipart/form-data格式包含了文件数据。

(3) application/json 抓取系统的 "上传简历" 功能:

  1. POST https://v.bitedu.vip/tms/login HTTP/1.1
  2. Host: v.CSDN.vip
  3. Connection: keep-alive
  4. Content-Length: 105
  5. sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
  6. sec-ch-ua-mobile: ?0
  7. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  8. like Gecko) Chrome/91.0.4472.101 Safari/537.36
  9. Access-Control-Allow-Methods: PUT,POST,GET,DELETE,OPTIONS
  10. Content-Type: application/json;charset=UTF-8
  11. Access-Control-Allow-Origin: *
  12. Accept: application/json, text/plain, */*
  13. Access-Control-Allow-Headers: Content-Type, Content-Length, Authorization,
  14. Accept, X-Requested-With , yourHeaderFeild
  15. Origin: https://v.CSDN.vip
  16. Sec-Fetch-Site: same-origin
  17. Sec-Fetch-Mode: cors
  18. Sec-Fetch-Dest: empty
  19. Referer: https://v.CSDN.vip/login
  20. Accept-Encoding: gzip, deflate, br
  21. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  22. Cookie: rememberMe=true; username=123456789
  23. {"username":"123456789","password":"xxxx","code":"u58u","uuid":"9bd8e09ea27b48cd
  24. acc6a6bc41d9f462"}

这是一个通过POST请求发送JSON数据的示例。下面是对这个请求的分析:

  1. 请求方法:这是一个HTTP POST请求。

  2. 请求目标:请求的URL是 https://v.CSDN.vip/tms/login 。

  3. 请求头部:

    • Host: v.bitedu.vip 是请求的主机名。
    • Connection: keep-alive 表示要保持长连接。
    • Content-Length: 105 表示请求正文的长度为105字节。
    • sec-ch-ua, sec-ch-ua-mobile, User-Agent, Access-Control-Allow-Methods, Content-Type, Access-Control-Allow-Origin, Accept, Access-Control-Allow-Headers, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段,包含了与请求相关的各种信息,包括用户代理信息(User-Agent)、允许的请求方法(Access-Control-Allow-Methods)、CORS相关信息、来源(Referer)、Cookie等。
  4. 请求正文(Body):

    • 请求正文以JSON格式发送,Content-Type 字段指明了请求的内容类型为application/json;charset=UTF-8,字符编码为UTF-8。
    • JSON数据包含在大括号 {} 内,包含了以下字段:
      • username: "123456789"
      • password: "xxxx"
      • code: "u58u"
      • uuid: "9bd8e09ea27b48cdacc6a6bc41d9f462"

这个请求的主要目的是向 https://v.CSDN.vip/tms/login 发送一个JSON数据,包含了用户名、密码、验证码等信息。请求头中包含了一些与请求相关的信息,包括用户代理(User-Agent)、CORS设置、来源(Referer)、Cookie等。

HTTP 响应详解

HTTP响应是服务器对客户端请求的回复。每次你在浏览器中输入一个URL、点击一个链接或者通过其他方式进行网络请求,都会收到一个HTTP响应。HTTP响应由三部分组成:状态行、响应头和响应正文。

状态行:这是响应的第一行,包含了HTTP版本、状态码和状态描述。例如:"HTTP/1.1 200 OK"。

认识 "状态码" (status code)

HTTP响应的状态码(Status Code)是用于表示请求处理结果的三位数字代码,表示访问一个页面的结果。每个状态码对应一种不同的响应情况,用于通知客户端发出的请求是否成功,或者出现了什么问题。

状态码:状态码是一个三位数,用于表示请求的处理结果。状态码的第一个数字定义了响应的类别:

  • 1xx:信息响应。表示请求已接收,继续处理。
  • 2xx:成功。表示请求已被成功接收、理解和接受。
  • 3xx:重定向。要完成请求,需要进一步操作。
  • 4xx:客户端错误。请求包含语法错误或无法完成。
  • 5xx:服务器错误。服务器在处理请求时发生错误。

以下是一些常见的HTTP状态码:

  1. 200 OK:这是最常见的状态码,表示请求已成功处理。服务器已返回请求的数据。

  2. 201 Created:表示请求已经成功,并且服务器创建了一个新的资源,通常在POST请求成功后返回。

  3. 204 No Content:表示请求已成功处理,但响应不包含实体主体。通常用于DELETE请求。

  4. 400 Bad Request:客户端请求有语法错误,服务器无法理解。

  5. 401 Unauthorized:表示需要进行身份验证或者认证信息无效,通常要求用户提供有效的用户名和密码。

  6. 403 Forbidden:服务器已经理解请求,但拒绝执行它,通常是因为权限不足。

  7. 404 Not Found:请求的资源未找到。

  8. 500 Internal Server Error:表示服务器在执行请求时出现了错误,客户端通常无法解决。

  9. 502 Bad Gateway:服务器作为网关或代理,从上游服务器接收到无效响应。

  10. 503 Service Unavailable:服务器当前无法处理请求,通常是因为服务器过载或正在维护。

这些状态码帮助客户端理解请求的结果,根据不同的状态码,客户端可以采取相应的行动。HTTP协议还有许多其他状态码,每个状态码都有特定的含义。理解这些状态码有助于开发者和系统管理员更好地诊断和解决HTTP请求和响应的问题。

认识重定向

重定向是一种HTTP响应机制,用于将客户端请求从一个URL(通常是A)重定向到另一个URL(通常是B)。重定向是服务器向客户端发出的指令,告诉客户端重新发起请求,但这次请求的目标是新的URL。

HTTP重定向通常用于以下情况:

  1. 永久重定向——资源永久移动:HTTP状态码301 Moved Permanently表示资源的位置已永久移动到新的URL,客户端应该将以后的请求直接发送到新的URL。可缓存。

  2. 临时重定向——资源临时移动:HTTP状态码302 Found表示资源的位置已临时移动到新的URL,客户端应该发送下一个请求到新的URL。这个重定向可能只是暂时的。不可缓存。

  3. 登录或认证:网站可能要求用户登录或提供身份验证信息才能访问某些资源。如果用户尚未登录或未提供必要的身份验证信息,服务器可能返回一个重定向响应,将用户引导到登录页面。

  4. URL重写或规范化:有时,服务器将对URL进行规范化或重写,以确保一致性和遵循最佳实践。这可以通过重定向来实现。

很多时候页面跳转也可以通过重定向来实现,还有的时候某个网站/服务器迁移了(IP/域名改变),就可以给旧的地址一个重定向响应,访问地址就会 

重定向在Web开发和网站维护中非常常见,用于多种情况,包括页面跳转和处理服务器迁移。以下是一些常见的应用情景:

  1. 页面跳转:重定向经常用于实现页面跳转,如从一个URL重定向到另一个URL。这可以用于用户登录后自动跳转到他们的个人资料页面,或者从旧的URL跳转到新的URL以维护网站的结构和导航。

  2. 服务器迁移:当网站的服务器或IP地址发生变化时,服务器可以向旧的地址发送重定向响应,将访问者引导到新的地址。这有助于确保旧的链接仍然有效,避免了断裂的链接和丢失的访问者。

  3. SEO优化:在搜索引擎优化(SEO)方面,重定向是维护网站的排名和搜索引擎索引的关键工具。当网页的URL结构发生变化时,通过使用301永久重定向,可以将搜索引擎引导到新的URL,以确保排名和索引的连续性。

  4. 身份验证和授权:网站可能会使用重定向来引导用户进行身份验证,例如在用户未登录时将他们重定向到登录页面。一旦登录成功,他们将被重定向回原始请求的页面。

重定向是HTTP协议的一个强大特性,它允许网站管理者以一种用户友好的方式维护网站结构,同时确保访问者能够访问所需的内容。这对于提供良好的用户体验和维护网站的可用性至关重要。

总的来说,重定向是HTTP中的一种重要机制,允许服务器将客户端请求引导到新的URL,以实现资源的移动、登录、规范化等目的。客户端收到重定向响应后,会自动向新的URL重新发送请求。

200 OK

这是一个最常见的状态码, 表示访问成功。

抓包抓到的大部分结果都是 200:

例如访问搜狗主页:

  1. HTTP/1.1 200 OK
  2. Server: nginx
  3. Date: Thu, 10 Jun 2021 06:07:27 GMT
  4. Content-Type: text/html; charset=utf-8
  5. Connection: keep-alive
  6. Vary: Accept-Encoding
  7. Set-Cookie: black_passportid=; path=/; expires=Thu, 01 Jan 1970 00:00:00
  8. GMT; domain=.sogou.com
  9. Pragma: No-cache
  10. Cache-Control: max-age=0
  11. Expires: Thu, 10 Jun 2021 06:07:27 GMT
  12. UUID: 80022370-065c-49b0-a970-31bc467ff244
  13. Content-Length: 14805
  14. <!DOCTYPE html><html lang="cn"><head><meta name="viewport"
  15. content="width=device-width,minimum-scale=1,maximum-scale=1,userscalable=no"><script>window._speedMark = new Date(); window.lead_ip =
  16. '1.80.175.234';
  17. ......

注意:在抓包观察响应数据的时候, 可能会看到压缩之后的数据, 形如:

网络传输中 "带宽" 是一个稀缺资源,为了传输效率更高往往会对数据进行压缩。

 点击 Fiddler 中的 

即可进行解压缩,看到原始的内容。

404 Not Found

  1. HTTP/1.1 404 Not Found
  2. Server: nginx
  3. Date: Thu, 10 Jun 2021 05:19:04 GMT
  4. Content-Type: text/html
  5. Connection: keep-alive
  6. Vary: Accept-Encoding
  7. Content-Length: 564
  8. <html>
  9. <head><title>404 Not Found</title></head>
  10. <body bgcolor="white">
  11. <center><h1>404 Not Found</h1></center>
  12. <hr><center>nginx</center>
  13. </body>
  14. </html>

403 Forbidden

HTTP状态码403表示访问被服务器拒绝,通常由于权限问题或认证问题引起。这表示客户端请求了一个资源,但服务器认为客户端没有足够的权限来访问该资源。

常见的情况包括:

  1. 需要身份验证: 服务器上的资源要求用户进行身份验证,例如登录,以便访问。如果客户端没有提供有效的凭据或未登录,服务器将返回403错误。

  2. 权限不足: 即使用户已登录,但他们可能没有足够的权限来访问特定资源。这可能是由于角色、许可或其他授权问题引起的。

  3. 私有资源: 有些资源被标记为私有,只有特定的用户或组可以访问它们。如果用户不属于这些组,他们将被拒绝访问。

  4. IP过滤或防火墙规则: 有时服务器配置了IP过滤或防火墙规则,只允许特定IP地址或范围的IP地址访问资源。如果客户端IP不在白名单中,它将收到403错误。

403 Forbidden与404 Not Found不同,后者表示资源未找到,而前者表示资源存在但不可访问。通常,服务器会在403响应中提供有关拒绝访问的详细信息,以帮助客户端了解拒绝的原因。这有助于维护资源的安全性和访问控制。

 例如: 查看码云的私有仓库, 如果不登陆, 就会出现 403。

  1. HTTP/1.1 403 Forbidden
  2. Date: Thu, 10 Jun 2021 06:05:36 GMT
  3. Content-Type: text/html; charset=utf-8
  4. Connection: keep-alive
  5. Keep-Alive: timeout=60
  6. Server: nginx
  7. Vary: Accept-Encoding
  8. X-XSS-Protection: 1; mode=block
  9. X-Content-Type-Options: nosniff
  10. X-UA-Compatible: chrome=1
  11. Expires: Sun, 1 Jan 2000 01:00:00 GMT
  12. Pragma: must-revalidate, no-cache, private
  13. Cache-Control: no-cache
  14. Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041
  15. 06:05:40 -0000
  16. Set-Cookie: gitee-sessionn=ejEvQnYza2RlaXh0KzRaN3QrNWI2TzdLOE03bU5UNjRKdGlqWUFkMlJ2YktWYTRtcEtIVExOZE
  17. dJSFJFSkdiWmcxNmhjSTdneUZFaHFtalNKQUJWcDlUNDZYd2lBaElXNy9FaWRHQkl4d2RsS1RIWn
  18. RCNFphQm5JUjZOdjdsSDh5TlNvZ3hZdTBXNXUrU2c2azN2UVNFOWwyQnJvQzZ6MEluaEFFYnRoV0
  19. luOFlNWEEzWlR0K1g4WDlQRjNkSlNjZ1pUMGc0YkhreVNJMUV4YkVUUk0weXFqbGhQYzN5djA2bF
  20. Jyc3o4MHRVWkkxcHdQVG5abmJ2NmlqV1dEYjlWaUpNNno3UGFpZ3lsb1RqeXAranFHRlE9PS0tdU
  21. 5JMGZ3UUpwODRYdjF1MXdyYmFKUT09--52babe9c2dcb63fa02bc32d25bc0e854f4065f5f;
  22. domain=.gitee.com; path=/; HttpOnly
  23. X-Request-Id: 82a740fb98838c305c4cc597ab6f48c0
  24. X-Runtime: 0.020299
  25. Content-Length: 7092
  26. <!DOCTYPE html>
  27. <html>
  28. <head>
  29. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  30. <title>您的访问受限 (403)</title>
  31. ......

405 Method Not Allowed 

当客户端发送了一个服务器不支持的HTTP请求方法时,服务器会返回405状态码,表示请求方法不被允许或不被支持。

这通常发生在以下情况下:

  1. 服务器不支持该方法: 服务器可能只支持特定的HTTP请求方法,例如只支持GET和POST,而不支持PUT或DELETE等其他方法。

  2. URL路径不匹配: 有时服务器可能要求特定的URL路径才能使用某些HTTP方法。如果请求的URL路径不匹配要求,服务器也可能返回405状态码。

  3. 权限问题: 服务器可能要求用户进行身份验证或授权,以便使用某些HTTP方法,如果客户端未提供有效的凭据或权限不足,服务器会返回405状态码。

客户端应该检查响应中的允许的方法列表(通常包含在响应头中的"Allow"字段)以了解服务器支持哪些HTTP方法。这有助于客户端更好地与服务器互动,并采取适当的措施,以符合服务器的要求。

500 Internal Server Error

这个状态码表示服务器在处理客户端请求时遇到了内部错误,通常是由于服务器的代码执行过程中出现异常、崩溃或其他不可预测的问题导致的。

一般情况下,正常运行的网站不应该频繁返回500错误,因为这意味着服务器出现了问题。然而,偶尔会发生内部错误,例如服务器端的代码错误、数据库连接问题、资源不足等,这些问题都可能导致500错误。对于网站运维团队来说,监控和及时处理500错误是非常重要的,以确保网站的稳定性和可用性。

对于用户来说,500错误通常表示网站暂时无法提供服务,可能需要稍后再次尝试,或者联系网站管理员以报告问题。这些错误通常不是用户引起的,而是服务器端的问题。

504 Gateway Timeout

HTTP状态码504 Gateway Timeout表示当客户端(通常是浏览器)向代理服务器(如反向代理服务器或网关)发送请求时,代理服务器等待服务器的响应,但由于服务器处理时间过长或超负荷,没有及时响应,导致超时。

这种情况经常发生在服务器负载非常高的情况下,例如大规模的促销活动、秒杀事件或其他突发的流量激增。服务器不仅要处理正常的请求,还要应对大量同时到达的请求,这可能导致服务器响应变慢,或者在某些情况下完全无法响应。当代理服务器等待服务器响应的时间超过了特定的超时阈值,就会返回504 Gateway Timeout错误,告知客户端请求超时。

这种情况通常需要网站管理员或开发人员采取措施,以增加服务器的处理能力,优化代码,缓解负载,或使用负载均衡等策略,以确保服务器能够在高负载时仍然提供可靠的服务。

这种情况在双十一等 "秒杀" 场景中容易出现, 平时不太容易见到。

302 Move temporarily

这个状态码表示请求的资源已被临时移到不同的URL,客户端应该使用新的URL来访问资源。与您的手机呼叫转移比喻类似,当客户端访问原始URL时,服务器将向客户端提供一个临时的新URL,客户端应该立即使用这个新URL来获取资源,而不需要告诉其他客户端或用户关于URL的更改。

HTTP状态码302通常用于以下情况:

  1. 临时更改: 资源的位置发生了临时更改,但未来可能会再次返回原始URL。这可以是因为维护、重定向到另一个服务器或其他原因。

  2. 用户会话管理: 在某些Web应用程序中,302状态码用于管理用户会话。例如,用户登录后,服务器可能会返回一个临时重定向以将用户导向他们的个人资料页面。

客户端收到302状态码后,应该遵循新的URL以获取资源,而不应该保留或缓存原始URL。这有助于确保客户端能够访问到实际的资源位置。

当用户成功登录时,服务器通常会向客户端发送302状态码,并在响应头中包含一个名为"Location"的字段,该字段指示要将客户端重定向到哪个URL。这是一种实现自动跳转到另一个页面的常见方式。

例如,如果用户成功登录,服务器会向客户端发送以下HTTP响应头:

  1. HTTP/1.1 302 Found
  2. Location: https://gitee.com/HGtz2222

客户端(通常是浏览器)会自动遵循这个重定向,向指定的URL发送GET请求,以获取新的页面或资源。在这种情况下,浏览器会自动跳转到"https://gitee.com/HGtz2222"页面,以实现登录后的导航到主页或其他目标页面。

这种重定向机制对于用户体验非常有用,因为它可以使用户无需手动点击链接或输入URL,而是在登录后自动跳转到目标页面。这在许多Web应用程序中都很常见,以提供便捷的用户体验。

301 Moved Permanently 

这个状态码表示资源的位置已永久移动到不同的URL,并且客户端应该使用新的URL来访问资源。与HTTP状态码302 Found(临时重定向)不同,301状态码表明资源已永久移动,客户端应该在后续的请求中自动使用新的URL。

当客户端(通常是浏览器)接收到带有301状态码的HTTP响应时,它会将原始URL与新的URL关联起来,并在后续请求中使用新的URL。这意味着即使用户尝试访问原始URL,他们也会被自动重定向到新的URL,无需手动更改或重新输入。

301状态码通常用于以下情况:

  1. 永久更改:资源的URL已永久更改,并且以后将不再使用原始URL。

  2. SEO和链接更新:网站所有者可能会使用301状态码来通知搜索引擎和其他站点,资源的新位置,以确保旧的链接被正确索引并引导到新的URL。

  3. URL重构:当网站重新组织或更改URL结构时,301状态码可用于确保以前的URL仍然引导到新的URL,以维护用户和搜索引擎的可用性。

总之,301 Moved Permanently状态码表示资源的永久重定向,它会在未来的请求中自动使用新的URL,确保用户能够访问到实际的资源位置。

418 I am a teapot!

418这个状态吗是HTTP 的 RFC文档中专门规定的一个状态码,这个状态码并没有实际的意义。

HTTP状态码418 "I'm a teapot" 是一个非常有趣的状态码,它在HTTP RFC文档中被定义为一种"彩蛋"或"愚人节玩笑"。这个状态码的描述是:“这个实体拒绝与一个被用茶壶冲泡咖啡的请求一同工作”。

它实际上没有实际用途,仅仅是HTTP协议的一种有趣的规定。通常情况下,这个状态码不会在正式的Web应用程序中使用,但它确实显示了HTTP规范的灵活性和幽默感。

这个状态码的背后是一种幽默,是HTTP规范中的一种娱乐元素,而不是用于真正的Web开发或通信。

状态码小结

使用不同的数字或代码来表示不同的状态或错误是一种非常常见的做法,不仅在HTTP状态码中,还在许多其他编程领域和协议中。这种做法有以下几个优点:

  1. 简单而有效:状态码或错误码的数字表示可以提供清晰而紧凑的信息,不需要冗长的描述。这使得通信更加高效。

  2. 标准化:通过使用标准化的状态码或错误码,不同的系统和应用程序可以共享相同的理解,而无需重新定义状态或错误。

  3. 易于处理:编程语言通常提供了处理错误码的工具,如C语言中我们接触过的ERROR错误码,有 strerror函数,使得开发人员能够更容易地理解和处理错误。

  4. 跨平台和跨语言:数字状态码通常不受特定编程语言或操作系统的限制,因此它们在不同平台和编程语言之间是可移植的。

认识响应 "报头" (header)

响应报头是HTTP响应的一部分,它包含了有关响应的元数据和属性,用于提供关于响应内容、服务器、缓存控制、Cookie等信息。

响应报头的基本格式与请求报头相似,通常由一个或多个键值对组成。这些键值对提供了有关响应的详细信息,如响应的内容类型(Content-Type)、内容长度(Content-Length)、服务器信息(Server)、响应日期(Date)、缓存控制(Cache-Control)、Cookie等等。这些信息对于客户端来说非常重要,因为它们影响着客户端如何处理响应、显示内容和与服务器交互。

以下是一些常见的响应报头属性和它们的含义:

  1. Content-Type: 指示响应主体的媒体类型,例如HTML、JSON、XML等。这有助于客户端正确解释响应的内容。

  2. Content-Length: 指示响应主体的长度,以字节为单位。客户端使用这个信息来确保完整接收响应。

  3. Server: 服务器标识,提供了有关响应的服务器的信息。

  4. Date: 响应生成的日期和时间。

  5. Cache-Control: 控制响应的缓存策略,如是否可以被缓存、缓存的过期时间等。

  6. Set-Cookie: 用于在响应中设置新的Cookie或更新已存在的Cookie。

  7. ETag(实体标签ETag(实体标签)是HTTP协议中的一个响应头属性,通常由服务器在响应中生成。ETag的目的是为了帮助缓存机制,允许客户端在后续请求中向服务器提供一个与之前响应的ETag匹配的标识,以检查资源是否发生了变化。

  8. 其他自定义报头:根据需要,可以在响应报头中包含自定义报头,以提供额外的元数据信息。

其中ETag的工作方式如下:

  1. 服务器为资源生成一个唯一的ETag标识,通常是资源内容的哈希值或其他标识。

  2. 服务器在HTTP响应的头部包含ETag标识。

  3. 客户端在后续请求中可以包含一个叫做"If-None-Match"的请求头,其中包含上一次响应的ETag值。

  4. 如果服务器接收到包含"If-None-Match"请求头的请求,并且该值与当前资源的ETag匹配,服务器可以返回状态码304(未修改),而不是重新发送资源。这意味着客户端可以使用之前缓存的资源,而不必重新下载。

ETag是一种有效的缓存控制机制,因为它允许服务器告诉客户端是否需要重新获取资源。这对于减少带宽使用和加快页面加载速度很有用。ETag通常用于与"Last-Modified"头一起使用,以提供更精确的缓存控制。

响应报头的内容对于客户端解释响应并采取适当的行动非常重要。不同的报头属性可以告诉客户端如何显示内容、如何缓存响应、如何处理Cookie等等。因此,了解响应报头对于理解和处理HTTP响应非常重要。

Content-Type

Content-Type是HTTP响应头中的一个重要字段,用于指示响应主体(response body)的数据格式。以下是一些常见的Content-Type值和它们的含义:

  1. text/html: 表示响应主体包含HTML文本。这通常用于HTML网页的响应,以便浏览器可以正确解释和呈现网页内容。
  2. text/css: 表示响应主体包含CSS(层叠样式表)数据,用于定义网页的样式和布局。
  3. application/javascript: 表示响应主体包含JavaScript代码,通常用于网页上的客户端脚本。
  4. application/json: 表示响应主体包含JSON(JavaScript Object Notation)数据,这是一种常用的数据交换格式,通常在API响应中使用。

这些Content-Type值有助于客户端(通常是浏览器或其他HTTP客户端)正确解释和处理响应主体的内容。当客户端收到响应时,它会查看Content-Type字段,以确定如何呈现或处理响应的数据。例如,如果Content-Type为text/html,则客户端会将内容解释为HTML并显示在浏览器中;如果Content-Type为application/json,则客户端会将内容解释为JSON,以便在JavaScript中处理。

认识响应 "正文" (body) 

  1. 响应正文:响应正文是响应的主要内容,通常包含HTML文本、JSON数据、图像、视频、文件等。响应正文的内容取决于请求的性质和服务器的响应。

  2. Content-Type:响应头中的Content-Type字段告诉客户端如何正确解释和处理响应的正文。根据Content-Type的值,客户端可以呈现文本、解析JSON、显示图像等。

响应头提供了与响应相关的元数据,如状态信息、响应类型和缓存控制。响应正文包含实际的数据或内容,如HTML页面、JSON数据或媒体文件。

正文的具体格式取决于 Content-Type。

(1)text/html

  1. Server: nginx/1.17.3
  2. Date: Thu, 10 Jun 2021 07:25:09 GMT
  3. Content-Type: text/html; charset=utf-8
  4. Last-Modified: Thu, 13 May 2021 09:01:26 GMT
  5. Connection: keep-alive
  6. ETag: W/"609ceae6-3206"
  7. Content-Length: 12806
  8. <!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible
  9. content="IE=edge,chrome=1"><meta name=renderer content=webkit><meta name=viewport
  10. content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user scalable=no"><link rel=icon href=/favicon.ico><title id=bodyTitle>芒果教务网
  11. </title><link href=https://cdn.bootcss.com/jquerydatetimepicker/2.5.20/jquery.datetimepicker.css rel=stylesheet><script
  12. src=https://cdn.bootcss.com/highlight.js/9.1.0/highlight.min.js></script><script
  13. src=https://cdn.bootcss.com/highlightjs-line-numbers.js/2.5.0/highlightjs-linenumbers.min.js></script><style>html,
  14. body,
  15. #app {
  16. height: 100%;
  17. margin: 0px;
  18. padding: 0px;
  19. }
  20. .chromeframe {
  21. margin: 0.2em 0;
  22. background: #ccc;
  23. color: #000;
  24. padding: 0.2em 0;
  25. }
  26. #loader-wrapper {
  27. position: fixed;
  28. top: 0;
  29. left: 0;
  30. width: 100%;
  31. height: 100%;
  32. z-index: 999999;
  33. }
  34. ......

提供的示例中,Content-Type为"text/html; charset=utf-8",表示响应正文的数据格式为HTML,并使用UTF-8字符编码。因此,响应正文包含了HTML代码,用于构建网页的内容。

以下是示例响应正文的一部分,其中包含HTML页面的结构和内容:

  1. <!DOCTYPE html>
  2. <html>
  3. <head>
  4. <meta charset=utf-8>
  5. <meta http-equiv=X-UA-Compatible content="IE=edge,chrome=1">
  6. <meta name=renderer content=webkit>
  7. <meta name=viewport content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no">
  8. <link rel=icon href=/favicon.ico>
  9. <title id=bodyTitle>芒果教务系统</title>
  10. <!-- 其他 HTML 标签和内容 -->
  11. </head>
  12. <body>
  13. <!-- 页面内容 -->
  14. </body>
  15. </html>

 这个响应正文包含HTML标记和内容,可以被浏览器正确解释和显示,以呈现网页的视觉和交互部分。

需要注意的是,根据Content-Type的不同,响应正文的格式和内容也会有所不同。例如,如果Content-Type是"application/json",那么响应正文将包含JSON数据,如果是"image/jpeg",那么响应正文将包含图像数据,以此类推。客户端会根据Content-Type来解释和处理响应正文的内容。

(2)text/css

  1. HTTP/1.1 200 OK
  2. Server: nginx/1.17.3
  3. Date: Thu, 10 Jun 2021 07:25:09 GMT
  4. Content-Type: text/css
  5. Last-Modified: Thu, 13 May 2021 09:01:26 GMT
  6. Connection: keep-alive
  7. ETag: W/"609ceae6-3cfbe"
  8. Content-Length: 249790
  9. @font-face{font-family:element-icons;src:url(../../static/fonts/elementicons.535877f5.woff) format("woff"),url(../../static/fonts/elementicons.732389de.ttf) format("truetype");font-weight:400;font-style:normal}
  10. [class*=" el-icon-"],
  11. ......

Content-Type为"text/css",这表示响应正文的数据格式为CSS(层叠样式表)。响应正文包含CSS样式的定义,这些样式规则用于设置网页的外观和布局。

以下是示例响应正文的一部分,其中包含了CSS样式的定义:

  1. @font-face {
  2. font-family: element-icons;
  3. src: url(../../static/fonts/element-icons.535877f5.woff) format("woff"), url(../../static/fonts/element-icons.732389de.ttf) format("truetype");
  4. font-weight: 400;
  5. font-style: normal;
  6. }
  7. [class*=" el-icon-"] {
  8. /* 其他 CSS 样式规则 */
  9. }

这个响应正文包含了字体定义以及CSS样式规则。这些规则用于设置网页上的各种元素的样式,包括字体、颜色、布局等。

浏览器将解释这些CSS规则并应用它们,以呈现页面的外观。CSS在Web开发中是非常重要的,因为它允许开发人员精确控制网页的外观和布局,以提供良好的用户体验。响应的Content-Type告诉浏览器如何正确解释和处理响应正文的内容。

(3) application/javascript

  1. HTTP/1.1 200 OK
  2. Server: nginx/1.17.3
  3. Date: Thu, 10 Jun 2021 07:25:09 GMT
  4. Content-Type: application/javascript; charset=utf-8
  5. Last-Modified: Thu, 13 May 2021 09:01:26 GMT
  6. Connection: keep-alive
  7. ETag: W/"609ceae6-427d4"
  8. Content-Length: 272340
  9. (window["webpackJsonp"]=window["webpackJsonp"]||[]).push([["app"],
  10. {0:function(t,e,n){t.exports=n("56d7")},"00b3":function(t,e,n){},"
  11. ......

Content-Type为"application/javascript; charset=utf-8",这表示响应正文的数据格式为JavaScript,并使用UTF-8字符编码。响应正文包含了JavaScript代码,这是用于客户端脚本的一部分。

以下是示例响应正文的一部分,包含JavaScript代码:

  1. (window["webpackJsonp"] = window["webpackJsonp"] || []).push([["app"], {
  2. 0: function(t, e, n) {
  3. t.exports = n("56d7");
  4. },
  5. "00b3": function(t, e, n) {},
  6. // 其他 JavaScript 代码
  7. }

 这个响应正文包含了JavaScript代码块,其中可能包括不同的模块、函数和变量。这些代码用于在客户端(通常是浏览器)上执行特定的逻辑,例如处理用户交互、修改DOM(文档对象模型)元素、发送HTTP请求等等。

JavaScript是一种广泛用于Web开发的脚本语言,它允许开发人员创建丰富的交互性和动态性的网页。HTTP响应中的JavaScript代码会被浏览器执行,以实现网页的客户端逻辑。浏览器将根据Content-Type 值来正确解释和处理响应正文中的JavaScript代码。

(4)application/json

  1. HTTP/1.1 200
  2. Server: nginx/1.17.3
  3. Date: Thu, 10 Jun 2021 07:25:10 GMT
  4. Content-Type: application/json;charset=UTF-8
  5. Connection: keep-alive
  6. X-Content-Type-Options: nosniff
  7. X-XSS-Protection: 1; mode=block
  8. Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  9. Pragma: no-cache
  10. Expires: 0
  11. vary: accept-encoding
  12. Content-Length: 12268
  13. {"msg":"操作成功","code":200,"permissions":[] }

Content-Type为"application/json;charset=UTF-8",这表示响应正文的数据格式为JSON(JavaScript Object Notation),并使用UTF-8字符编码。响应正文包含了一个JSON对象,用于传递数据。

以下是示例响应正文的JSON数据:

  1. {
  2. "msg": "操作成功",
  3. "code": 200,
  4. "permissions": []
  5. }

 这个JSON对象包含了键值对,其中键是字符串,值可以是字符串、数字、数组等。JSON是一种轻量级的数据交换格式,经常用于API响应,以便客户端和服务器之间传递结构化数据。

在这个示例中,JSON对象描述了一个操作的成功状态,包括一条消息 "操作成功"、状态码 "200",以及一个空数组 "permissions"。客户端可以解析JSON数据并使用其中的信息,以便在应用程序中采取适当的措施。

JSON作为一种数据格式在Web开发中非常常见,因为它易于阅读、编写和解析,并且通常与JavaScript一起使用,以便在客户端和服务器之间进行数据交换。Content-Type的值告诉客户端如何正确解释和处理响应正文中的JSON数据。

那么我们如何让客户端构造一个HTTP请求?如何让服务器处理一个HTTP请求?

客户端(通常是浏览器)构造HTTP请求是通过向服务器请求资源或执行特定操作的重要过程。下面是不同方式构造HTTP请求的一些方法:

浏览器构造HTTP请求:

  1. 手动输入URL:用户可以在浏览器的地址栏中手动输入URL,然后按回车键,这将构造并发送一个GET请求以获取指定资源。

  2. HTML标签:某些HTML标签可以触发HTTP请求。例如,<img>标签用于请求和显示图像资源,<a>标签用于导航到链接资源,<link>标签用于获取样式表,<script>标签用于获取和执行JavaScript文件等。

  3. 表单提交(重点!!!):HTML中的<form>元素允许用户填写数据并通过提交按钮触发HTTP请求。表单可以使用HTTP的GET或POST方法来发送数据,取决于表单的设置。

  4. AJAX的方式:form只支持GRT和POST,不支持其他方法,会触发页面给跳转,而我们有时候不想跳转。所以我们又引入AJAX。AJAX通过JS提供的API来构造HTTP请求,针对拿到的想要同样可以使用JS来灵活处理,想怎么处理都可以,给前端代码带来了更多的可操作空间。现在的网站主题都是通过AJAX的方式来交互的,浏览器原生提供了AJAX的API,但是很难用。还有一些第三方库,封装了AJAX,我们就使用这些封装的版本来操作。此处我们使用jQuery这个库封装的。

  5. 更简单更方便的方法:第三方工具实现:除了上述方法,还有许多第三方库和框架,如Axios, Fetch API等,它们提供了更加简洁、强大和灵活的方式来构造和发送HTTP请求。还有诸如Postman这样的工具,允许开发者手动构建、发送请求,并查看响应,特别适用于API的开发和测试。这是一种更简单的构造HTTP请求的方式,直接通过第三方工具,图形化界面来构造。我们

服务器处理HTTP请求(具体的以后介绍):

服务器接收和处理HTTP请求的过程通常涉及以下步骤:

  1. 接收请求:服务器监听指定端口,等待来自客户端的连接。一旦建立连接,服务器会接收HTTP请求。

  2. 解析请求:服务器解析HTTP请求的各个部分,包括请求行、请求头和请求正文。这使服务器能够了解客户端的请求类型、所请求的资源、请求头信息等。

  3. 路由和处理:根据请求的类型(GET、POST、PUT、DELETE等)和请求的URL,服务器将请求路由到适当的处理程序或控制器。服务器执行所需的操作,可以是检索资源、执行业务逻辑、保存数据等。

  4. 生成响应:服务器根据请求的处理结果构建HTTP响应。响应包括响应状态码、响应头和响应正文。

  5. 发送响应:服务器将HTTP响应发送回客户端,通常通过与客户端建立的TCP连接。客户端接收并解析响应,然后根据响应的内容执行相应的操作,如渲染页面、显示资源或处理数据。

服务器端的技术和框架(如Apache、NGINX、Node.js、Django、Spring等)通常用于处理HTTP请求,它们提供了路由、中间件、数据存储和业务逻辑执行等功能,以便有效地处理和响应来自客户端的请求。这些服务器端工具和框架可以大大简化服务器端的开发和维护工作。

通过 form 表单构造

HTTP 请求 form (表单) 是 HTML 中的一个常用标签。 可以用于给服务器发送 GET 或者 POST 请求。

注意:不要把 form 拼写成 from!!!

HTML\CSS\JS也是编程语言,他们和C还有Java这些语言的区别就在于它们是运行在浏览器上的,不像C要安装VS、Java要安装JDK。它们有浏览器就可以运行。

编写前端代码开发工具也有很多选择。IDEA是可选项,但是得十专业版才能支持HTML+CSS+JS。社区版只支持HTML。

所以相比之下,VSCode是一个更好的选择。

HTML(Hypertext Markup Language)是一种标记语言,用于创建网页的结构和内容。HTML标签是构成HTML文档的基本元素,它们定义了文档的结构和内容。

  1. <html>
  2. <head>
  3. </head>
  4. <body>
  5. hello world!!!
  6. </body>
  7. </html>
  1. 成对出现的标签:大多数HTML标签都是成对出现的,例如<div></div>, <h1></h1>, <p></p>等。开始标签<>,结束标签</>

  2. 单标签:有些HTML标签是单独的,它们通常不需要一个结束标签,例如<img>, <br><input>

  3. 嵌套标签:HTML标签内容里面还可以嵌套其他标签,以创建更复杂的结构,如<div><p>这是一个段落。</p></div>

  4. head和body

    • head:<head>标签中存放的是属性,通常包含元数据(metadata),如文档的字符编码、文档标题、连接的样式表、脚本等。
    • body:<body>标签中包含了用户在浏览器中看到的所有内容,如文本、图像、链接、表单等。
  5. 常见的HTML标签:在HTML里面dodou有哪些标签?每个标签的含义是什么?这些都是标准规定好的:

    • <!DOCTYPE>:文档类型声明,定义了文档所遵循的HTML版本和规范。

    • <html>:HTML文档的根元素,包含了整个文档。

    • <head>:包含了文档的元信息,如标题、字符集声明、样式表和脚本等。

    • <title>:定义网页的标题,显示在浏览器标签页上。

    • <meta>:提供关于文档的元信息,如字符集、作者、描述等。

    • <link>:用于链接外部样式表。

    • <style>:用于在文档中嵌入CSS样式。

    • <script>:用于嵌入JavaScript代码。

    • <body>:包含页面上实际显示的内容,如文本、图像、链接等。

    • <h1>, <h2>, <h3>, ... <h6>:定义标题,其中<h1>最高,<h6>最低。

    • <p>:定义段落。

    • <a>:创建超链接。

    • <img>:嵌入图像。

    • <ul>:创建无序列表。

    • <ol>:创建有序列表。

    • <li>:定义列表项。

    • <table>:创建表格。

    • <tr>:定义表格的行。

    • <td>:定义表格的数据单元格。

    • <th>:定义表格的表头单元格。

    • <div>:通用的块级容器,用于组织和布局内容。

    • <span>:通用的内联容器,用于包裹文本或内联元素。

HTML中都有那些标签,每个标签的含义是什么,这些都是标准规定的。

现代浏览器通常具有一定的容错性和鲁棒性,可以尽力解析并显示不规范的HTML代码。这种特性使得即使HTML代码存在一些错误或不规范,网页仍然可以在浏览器中正常显示(浏览器会尽可能的进行显示)。以下是一些浏览器的容错机制:

  1. 标签不闭合或嵌套错误: 浏览器会尝试自动纠正标签的闭合错误或嵌套错误,以便更好地显示内容。

  2. 缺失的属性: 如果HTML标签中缺少某些属性,浏览器会尝试使用默认值或进行猜测,以确保元素能够正确渲染。

  3. 不支持的标签和属性: 浏览器会忽略它们不理解的标签和属性,而显示它们能够理解的部分。

  4. 文档类型不一致: 如果文档声明(<!DOCTYPE>)不正确或缺失,浏览器也会尽力去解析并显示页面。

  5. 非法字符: 浏览器通常会忽略或替换文档中的非法字符,以防止它们导致页面解析失败。

尽管浏览器具有这些容错机制,但仍然建议编写符合HTML规范的代码,以确保最佳的跨浏览器兼容性和可维护性。不规范的HTML可能会导致解释不一致或难以维护的问题,因此良好的编码实践仍然非常重要。

还有一种更简单的编写方式:

直接输入“!”再输入<tab>,就会自动生成基本的HTML代码模板。

form 发送 GET 请求

用到form标签:

开始标签中可以写属性,就是一些“键值对”,可以有多个属性,多个键值对之间使用空格来分割。键和值之间使用“=”分割。键不需要需要有引号,值需要双引号。

表单form的重要参数

  1. action: 这是表单的 action 属性,用于指定HTTP请求的目标URL,即数据将被发送到哪个服务器资源。

  2. method: 表单的 method 属性,用于指定HTTP请求的方法,通常是GET或POST。表单只支持这两种方法。 

输入字段 input 的重要参数

  1. type: 输入字段的type属性,用于定义输入框的类型。例如,"text"表示文本输入框,"password"表示密码输入框,"submit"表示提交按钮。

  2. name: 输入字段的name属性,用于指定构造的HTTP请求的查询字符串(query string)中的键(key)。查询字符串的值将是用户在输入字段中输入的内容。

  3. value: input标签的value属性,对于类型为"submit"的输入字段来说,value对应了按钮上显示的文本、内容。例如,在一个提交按钮上,value可以设置为"提交",这将是按钮上显示的文本,但是必须得设置为“submit”类型。

这些参数帮助我们构建HTML表单,定义表单的行为和输入字段的类型。正确使用这些参数将有助于创建有效的HTTP请求表单。

演示一下d如何构建一个GET请求的HTML表单:

  1. <form action="http://abcdef.com/myPath" method="GET">
  2. <input type="text" name="userId">
  3. <input type="text" name="classId">
  4. <input type="submit" value="提交">
  5. </form>

页面展示的效果:

在输入框随便填写数据:

设置成“submit”类型才会是提交按钮,点击 "提交", 此时就会构造出 HTTP 请求并发送出去。 

当前虽然已经把请求构造出来了,但是当前得到的响应是404,因为还需要服务器这边的代码配合。

构造的 HTTP 请求

  1. GET http://abcdef.com/myPath?userId=100&classId=200 HTTP/1.1
  2. Host: abcdef.com
  3. Proxy-Connection: keep-alive
  4. Upgrade-Insecure-Requests: 1
  5. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
  6. like Gecko) Chrome/91.0.4472.114 Safari/537.36
  7. Accept:
  8. text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
  9. e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
  10. Accept-Encoding: gzip, deflate
  11. Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

注意: 由于我们的服务器的地址是随便写的, 因此无法获取到正确的 HTTP 响应 。

这是一个HTTP GET请求的示例,其中包含了请求头(request headers)和请求行(request line)。这个请求将被发送到目标URL http://abcdef.com/myPath?userId=100&classId=200

以下是请求的各个部分的解释:

请求行 (Request Line):

  • GET http://abcdef.com/myPath?userId=100&classId=200 HTTP/1.1:这是HTTP请求行。它指定了HTTP方法(GET)、请求的URL地址(http://abcdef.com/myPath?userId=100&classId=200),以及HTTP协议版本(HTTP/1.1)。

请求头 (Request Headers):

  • Host: abcdef.com:指定了请求的主机名,即请求被发送到哪个服务器。
  • Proxy-Connection: keep-alive:表示要保持代理连接保持活跃,以便在同一连接上发送多个请求。
  • Upgrade-Insecure-Requests: 1:表示浏览器要升级不安全的请求,以提高安全性。
  • User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36:包含了用户代理信息,描述了浏览器和操作系统等信息。
  • Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9:表示浏览器可以接受的媒体类型,按优先级排序。
  • Accept-Encoding: gzip, deflate:指示浏览器可以接受的内容编码方式,例如gzip和deflate。
  • Accept-Language: zh-CN,zh;q=0.9,en;q=0.8:指示浏览器接受的语言首选项,以便服务器返回适合的语言版本。

这个请求是一个HTTP GET请求,它向指定的URL发送请求以获取相应的资源。

体会 form 代码和 HTTP 请求之间的对应关系

HTML中的标签 form 与HTTP请求之间有着紧密的联系。当用户在浏览器中提交一个表单时,背后实际上是发起了一个HTTP请求:

  1. form的action属性与HTTP请求的URL

    • action属性在form 标签中定义了提交表单数据时要发送到的URL。
    • 当用户提交表单时,浏览器就会向此URL发起HTTP请求。

    例如,如果你的表单中有如下代码:

    <form action="http://abcdef.com/myPath" method="GET">

    当用户提交表单时,HTTP请求会发送到http://abcdef.com/myPath这个地址。

  2. form的method属性与HTTP请求的方法

    • form的method属性指定了HTTP请求的类型(例如GET或POST,form支支持dgett)。
    • 这决定了数据是作为URL的一部分(查询字符串)发送还是作为请求的主体发送。
  3. input的name属性与查询字符串的key

    • 每个input字段的name属性值将成为查询字符串中的一个键。

    例如,以下表单字段:

    <input type="text" name="userId">

    在用户提交表单后,如果输入了“100”,URL可能会包含userId=100 这样的查询字符串。

  4. input的内容与查询字符串的value

    • 用户在 input 字段中输入的内容将成为查询字符串中相应键的值。

    如果你有如上面的userId字段,并且用户在其中输入了“100”,那么查询字符串会有一个userId=100的部分。

演示图:

 

哈哈哈笑死我了两位鸡哥再用棒槌互殴……

很明显,当前我们得到的响应是一个404,要想有一个正确的响应往往还需要服务器这边的配合。 

 

总之,当你查看或编写HTML表单代码时,可以预见它在背后如何生成HTTP请求。理解这种对应关系有助于调试问题、优化用户体验,并确保数据正确地发送到服务器。

form 发送 POST 请求

修改上面的代码, 把 form 的 method 修改为 POST。

  1. <form action="http://abcdef.com/myPath" method="POST">
  2. <input type="text" name="userId">
  3. <input type="text" name="classId">
  4. <input type="submit" value="提交">
  5. </form>

页面效果不变。  

当然,对于GET来说,这几个键值对是在URL中,对于POST来说,这几个键值对就在body中了。

通过AJAX的方式构造

AJAX 全称 Asynchronous Javascript And XML, 是 2005 年提出的一种 JavaScript 给服务器发送 HTTP 请求的方式。 特点是可以不需要 刷新页面/页面跳转 就能进行数据传输。

在 JavaScript 中可以通过 ajax 的方式构造 HTTP 请求

注意: 为了验证 ajax 的功能, 需要提前准备好一份配套的服务器程序. 这个代码已经部署在 http://42.192.83.143:8080/AjaxMockServer/info 

AJAX(Asynchronous JavaScript and XML)

  • 异步性:其主要特征是异步,即在数据被请求和接收之间,用户可以继续执行其他操作。

  • 技术组合:AJAX并不仅限于XML格式;尽管它的名字中有“XML”,但现在,JSON更为常用。

  • JavaScript构造请求:使用浏览器提供的XMLHttpRequest对象,开发者可以构造和发送HTTP请求,以及处理HTTP响应。

  • 页面无刷新更新:一旦收到服务器的响应,可以使用JavaScript来更新页面的某部分,而无需加载新的页面。

验证AJAX的功能: 提供的服务器http://42.192.83.143:8080/AjaxMockServer/info允许验证AJAX请求的功能。用户或开发者可以使用这个服务器来测试发送的AJAX请求并查看响应。

例如,使用原生的JavaScript构造一个简单的AJAX请求:

  1. var xhr = new XMLHttpRequest();
  2. xhr.open('GET', 'http://42.192.83.143:8080/AjaxMockServer/info', true);
  3. xhr.onreadystatechange = function() {
  4. if (xhr.readyState == 4 && xhr.status == 200) {
  5. var response = JSON.parse(xhr.responseText);
  6. console.log(response);
  7. }
  8. };
  9. xhr.send();

这个简单的示例演示了如何使用原生JavaScript构造一个GET请求。当请求完成并收到服务器响应时,响应数据会被打印到控制台。 

发送 GET 请求

代码格式如此:

"application/x-www-form-urlencoded" 数据格式

  1. // 使用jQuery的$.ajax()发送application/x-www-form-urlencoded GET 请求
  2. $.ajax({
  3. url: "http://example.com/api?name=John&age=30&city=New+York",
  4. type: "GET",
  5. success: function(response) {
  6. console.log(response);
  7. },
  8. error: function(jqXHR, textStatus, errorThrown) {
  9. console.error("请求失败: " + textStatus);
  10. }
  11. });

在这个示例中,GET 请求的数据是作为查询字符串附加到 URL 中的。查询字符串以 ? 开头,键值对以 & 分隔。这个格式通常用于 GET 请求,其中参数以键值对的形式传递给服务器。

如果你希望在 GET 请求中发送更多参数,只需在 URL 的查询字符串中添加更多键值对,如下所示:

url: "http://example.com/api?param1=value1&param2=value2&param3=value3"

 服务器端会解析查询字符串,并从中提取相应的参数和值,然后执行相应的操作。这是在浏览器中构造 "application/x-www-form-urlencoded" GET 请求的方式之一。

  1. <head> <!DOCTYPE html>
  2. <html lang="en">
  3. <head>
  4. <meta charset="UTF-8">
  5. <meta name="viewport" content="width=device-width, initial-scale=1.0">
  6. <title>ajax</title>
  7. </head>
  8. <body>
  9. <!-- 1. 引入jQuery库 -->
  10. <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
  11. <script>
  12. $(document).ready(function() {
  13. //这个写法是定义变量,不需要写类型,不管什么类型都是let。
  14. //变量的具体的类型是根据 = 后面初始化的值的类型来确定的
  15. //此处的'1'是字符串,value1变量的类型也就是字符串了。
  16. let value1='1';
  17. // 2. 编写JS代码
  18. $.ajax({
  19. // 3. 定义对象属性
  20. url: "http://42.192.83.143:8080/AjaxMockServer/info", // 请求的URL
  21. type: "GET", // HTTP方法
  22. dataType: "json", // 预期服务器返回的数据类型
  23. success: function(response) { // 3. 回调函数
  24. // 4. 此处的形参就是HTTP响应的body内容
  25. console.log(response); // 打印响应数据
  26. // 5. 定义变量
  27. let value1 = '1';
  28. console.log(value1);
  29. },
  30. error: function(jqXHR, textStatus, errorThrown) {
  31. console.error("请求失败: " + textStatus);
  32. }
  33. });
  34. });
  35. </script>
  36. </body>
  37. </html></head>

 

右键点击,打开网页控制台(检查),然后发现还是报错。

还是要和服务器交互才可以正常运行。

解释:

1、引入jQuery库(第三方库,是需要额外下载引入的)。前端引入第三方库是非常容易的,只需要代码中写一个库的地址就好。你可以从官方网站或CDN获取,并通过<script>标签引入。

<script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.7.1/jquery.min.js"></script>

2、编写JS代码:$.ajax(); $是一个变量名,全局变量,在jQuery中定义的。通过这个变量来调用一些方法使用其中的API;我们使用jQuery提供的$.ajax(); 方法来执行AJAX请求。

3、在 $.ajax(); 中,JS的 { }表示一个对象。里面是使用键值对的方式来描述“属性名”和“属性值”的。我们定义了一个对象,它描述了请求的详细信息和如何处理响应。

这和我们之前提到的JSON很像,它就出自于这里。这里对象的属性的值也可以是一个函数。这个函数是一个匿名的函数,也就相当于lamba表达式。success这个函数不是立即执行的,而是服务器返回200这样的响应的时候才会执行到。这个函数的执行时机不是程序猿自己定义的,而是在合适的时候自动被调用的。像这样的函数就是“回调函数”。当然,其实也可以这样,但是不太常用:

  1. <body>
  2. <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.7.1/jquery.min.js"></Script>
  3. <script>
  4. function callback(body){
  5. }
  6. $.ajax({
  7. // 3. 定义对象属性
  8. url: "http://42.192.83.143:8080/AjaxMockServer/info", // 请求的URL
  9. type: "GET", // HTTP方法
  10. dataType: "json", // 预期服务器返回的数据类型
  11. success: callback,
  12. });
  13. </script>
  14. </body>

4、此处的形参就是HTTP响应的body内容。

5、let value1=' 1 '。这个写法就是定义变量,不需要写类型,不管什么类型都是let。变量具体类型是根据=后面初始化的值的类型来确定的。此处' 1 '是一个字符串,value1变量类型也就是字符串了。

6、注意: 如果把 send 中的地址改成其他服务器的地址(比如 http://www.sogou.com/index.html 这 种), 大概率是会出错的。错误形如:

这个错误是因为 ajax 默认不能 "跨域", 也就是 "百度下面的 html 中的 ajax 不能访问 搜狗 的内容"。 这样的设定也是完全合理的。 如果想要强行进行跨域, 则需要服务器进行配合,在服务器的响应中 "允许跨域" 才可以。 咱们的示例服务器 42.192.83.143:8080/AjaxMockServer/info 进行了允许跨域设置, 因此我们的页面才能访问到其中的数据。

当你从一个域名(例如:baidu.com)上的网页尝试请求另一个不同域名(例如:sogou.com)上的资源时,浏览器默认出于安全考虑会阻止这样的请求。这种安全策略称为同源策略(Same-Origin Policy)。

浏览器有一种安全机制叫做"同源策略"(Same-Origin Policy),它限制了一个网页只能请求来自同一源的资源,不允许跨域请求。"同一源"指的是协议(如http和https)、主机名、端口号都相同。

当你使用XMLHttpRequest或fetch等方式发送HTTP请求到一个不同源的服务器(如将send中的地址改成"http://www.sogou.com/index.html",而你的网页源自不同的域),浏览器会阻止这个请求,并在控制台中报告跨域错误。这是出于安全考虑,以防止恶意网站获取到其他网站的数据。

如果确实需要进行跨域请求,服务器端需要设置合适的CORS(跨域资源共享)响应头来允许跨域请求。这是一个服务器端的配置,要求目标服务器明确指定允许哪些源进行跨域访问,哪些HTTP方法被允许,以及是否可以携带身份认证信息(如cookies)等。

由于"http://42.192.83.143:8080/AjaxMockServer/info"服务器设置了跨域策略,所以网页可以成功访问该地址。但如果尝试访问一个没有设置CORS策略的不同源服务器,就会遇到跨域错误。

跨域请求有以下几个要点

  1. 同源策略:为了网页安全,浏览器实施了同源策略,只允许网页请求与自己同源的数据,不允许跨域请求。

  2. 跨域资源共享(CORS):是一种解决跨域问题的方式。服务器可以在响应头中添加特定的Access-Control-Allow-Origin字段,允许来自其他域名的请求。

    例如:服务器设置Access-Control-Allow-Origin: *表示允许所有域名进行跨域请求。服务器也可以指定某个具体的域名。

  3. 前端解决方法

    • 使用JSONP(JSON with Padding):这是一个老的解决方案,它利用<script>标签没有跨域限制的特点进行数据请求。
    • 使用CORS:需要服务器配合设置相关的响应头。
  4. 后端解决方法

    • 设置CORS响应头。
    • 使用代理服务器:即前端发送请求到自己的服务器,然后由自己的服务器去请求其他服务器的数据。

我们提到的示例服务器42.192.83.143:8080/AjaxMockServer/info已经设置了允许跨域的响应头,所以页面可以成功地访问到它的数据。如果没有这个设置,就会看到浏览器控制台中关于CORS的错误提示。

浏览器和服务器交互过程(引入 ajax 后):

发送 POST 请求

在HTTP请求中,GET请求通常不发送"application/json"数据格式。GET请求的数据通常附加到URL的查询字符串中,使用"application/x-www-form-urlencoded"格式或类似的形式。

"application/x-www-form-urlencoded"和"application/json"是两种不同的数据传输格式,通常用于POST请求。POST请求允许发送各种不同的数据格式,包括这两种。

因此,对于GET请求,它没有在请求中明确指定数据格式,因为GET请求通常不需要像POST请求那样指定数据格式。对于GET请求,数据是附加到URL的查询字符串中。

如果你使用POST请求,可以根据需要选择发送"application/x-www-form-urlencoded"或"application/json"数据格式,这将取决于服务器端期望接收的数据格式。一般来说,"application/json"用于发送结构化的JSON数据,而"application/x-www-form-urlencoded"用于发送键值对数据。

发送 "application/x-www-form-urlencoded" 数据和发送 "application/json" 数据是两种不同的数据格式,通常在HTTP POST请求中用于向服务器发送数据。

  1. "application/x-www-form-urlencoded" 数据格式

    • 这是最常见的一种数据格式,类似于HTML表单提交时的数据格式。
    • 数据被编码为键值对的形式,使用key=value的格式,多个键值对之间使用&符号分隔。
    • 例如,以下数据使用该格式:name=John&age=30&city=New+York

    这种格式通常用于HTML表单的POST请求,或在AJAX请求中模拟表单数据的传输。服务器端通常会解析这种数据格式以获取用户提交的表单数据。

  2. "application/json" 数据格式

    • 这是一种更灵活的数据格式,通常用于传输结构化数据,如JavaScript对象。
    • 数据以JSON(JavaScript Object Notation)格式编码,使用键值对的形式,键和值之间使用冒号分隔,多个键值对之间使用逗号分隔,通常包裹在花括号中。
    • 例如,以下数据使用该格式:{"name":"John","age":30,"city":"New York"}

    这种格式通常用于API请求和响应,以传递复杂的数据结构,如对象或数组。服务器端通常会解析JSON数据以获取和处理请求中的数据

"application/x-www-form-urlencoded" 数据格式

  1. // 使用jQuery的$.ajax()发送application/x-www-form-urlencoded数据
  2. $.ajax({
  3. url: "http://example.com/api",
  4. type: "POST",
  5. data: "name=John&age=30&city=New+York",
  6. contentType: "application/x-www-form-urlencoded",
  7. success: function(response) {
  8. console.log(response);
  9. },
  10. error: function(jqXHR, textStatus, errorThrown) {
  11. console.error("请求失败: " + textStatus);
  12. }
  13. });

data属性中包含了以键值对形式编码的数据,contentType被设置为"application/x-www-form-urlencoded",以告诉服务器数据的格式。这种格式通常用于模拟HTML表单的POST请求或向服务器传递简单的键值对数据。 

"application/json" 数据格式: 

需要设置 body 的内容

代码格式如此:

  1. <!DOCTYPE html>
  2. <html lang="en">
  3. <head>
  4. <meta charset="UTF-8">
  5. <meta http-equiv="X-UA-Compatible" content="IE=edge">
  6. <meta name="viewport" content="width=device-width, initial-scale=1.0">
  7. <title>AJAX POST Request</title>
  8. <!-- 引入jQuery库 -->
  9. <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
  10. </head>
  11. <body>
  12. <script>
  13. $(document).ready(function() {
  14. // 编写JS代码
  15. $.ajax({
  16. // 定义对象属性
  17. url: "http://42.192.83.143:8080/AjaxMockServer/post", // 请求的URL
  18. type: "POST", // 使用POST方法
  19. data: JSON.stringify({ key: "value" }), // POST请求的数据,这里使用JSON格式
  20. contentType: "application/json", // 请求数据的类型
  21. dataType: "json", // 预期服务器返回的数据类型
  22. success: function(response) { // 处理响应的回调函数
  23. console.log(response); // 打印响应数据
  24. },
  25. error: function(jqXHR, textStatus, errorThrown) {
  26. console.error("请求失败: " + textStatus);
  27. }
  28. });
  29. });
  30. </script>
  31. </body>
  32. </html>
  1. 使用POST方法:在type属性中指定为"POST",而不是之前的"GET"。

  2. 提供POST数据:在data属性中指定POST请求的数据。这里使用JSON.stringify()将数据转换为JSON格式。

  3. 设置contentType属性:指定请求数据的类型为"application/json"。

练习:

1、以下关于HTTP协议叙述正确的是 ()

A.HTTP协议是建立在 TCP/IP 协议之上的网络层规范,分为三个部分:状态行、请求头、消息主体

B.Cookie数据在消息主体(body)中传输

C.HTTP协议支持一定时间内的TCP连接保持,这个连接可以用于发送/接收多次请求

D.HTTP是有状态的,每个请求都是独立的

答案:C

A. HTTP协议是建立在TCP/IP协议之上的应用层协议,而不是网络层协议。HTTP请求消息通常分为三个部分:状态行、请求头、消息主体。状态行包含了请求的方法(GET、POST等)、URI和协议版本等信息。请求头包含了请求的各种参数和元数据,而消息主体包含实际的请求数据(例如,POST请求中的表单数据)。因此,选项 A 中的描述关于HTTP的结构基本正确,但有关协议层级的描述不准确。

B. Cookie数据通常不会在HTTP消息的消息主体中传输。Cookie数据是通过HTTP请求头中的"Cookie"字段发送给服务器,以便服务器可以识别和跟踪用户的会话状态。消息主体通常包含实际的请求数据,如表单数据或内容,但与Cookie数据通常没有直接关联。因此,选项 B 是不准确的。

C. 正确。HTTP协议支持持久连接,也称为"HTTP Keep-Alive"或"持续连接"。这意味着在一定时间内,客户端和服务器之间的TCP连接可以被保持打开,以便在同一连接上发送和接收多个HTTP请求和响应,而不必为每个请求都建立一个新的TCP连接。这有助于减少连接建立和断开的开销,提高性能。

D. HTTP协议是一种无状态协议,即每个HTTP请求都是独立的,服务器不会自动记住之前的请求信息。如果需要在不同请求之间保持状态,通常需要使用一些机制,如Cookies、Session等来实现。因此,选项 D 中的描述是不准确的。

2、以下关于http和https说法不正确的是()

A.http协议通常使用80端口

B.https协议通常使用445端口

C.http协议是无状态的

D.https在http的基础上增加ssl层

答案:B

A. HTTP协议通常使用80端口: HTTP(Hypertext Transfer Protocol)是用于在Web上传输数据的协议,通常使用80端口。当您在浏览器中输入一个网址时,浏览器会默认使用HTTP,除非网址指定了不同的协议。HTTP协议的标准端口是80,因此服务器监听此端口以接收HTTP请求。

B. HTTPS协议通常使用445端口: 这是不正确的陈述。HTTPS(Hypertext Transfer Protocol Secure)是HTTP的安全版本,通常使用端口443。HTTPS通过使用SSL(Secure Sockets Layer)或TLS(Transport Layer Security)来对数据进行加密和安全传输。端口443是HTTPS的默认端口,而不是445。

C. HTTP协议是无状态的: HTTP是一种无状态协议,这意味着每个HTTP请求都是独立的,服务器不会保持客户端的状态信息。如果需要跟踪用户的状态,通常使用会话(Session)或Cookie等机制来维护状态信息。

D. HTTPS在HTTP的基础上增加SSL层:HTTPS是HTTP的安全版本,它通过在HTTP上加入SSL或TLS层来保护数据的机密性和完整性。这一层的加入使通信更加安全,因此通常用于需要保护敏感信息的网站,如在线银行和电子商务网站。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/黑客灵魂/article/detail/892790
推荐阅读
相关标签
  

闽ICP备14008679号