http 使用curl发起https请求

http 使用curl发起https请求

今天一个同事反映，使用curl发起https请求的时候报错：“SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL

routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed”

很明显，验证证书的时候出现了问题。

使用curl如果想发起的https请求正常的话有2种做法：

方法一、设定为不验证证书和host。

在执行curl_exec()之前。设置option

$ch = curl_init();

......

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);

方法二、设定一个正确的证书。

本地ssl判别证书太旧，导致链接报错ssl证书不正确。

我们需要下载新的ssl 本地判别文件

http://curl.haxx.se/ca/cacert.pem

放到程序文件目录

curl 增加下面的配置

curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,true); ;

curl_setopt($ch,CURLOPT_CAINFO,dirname(__FILE__).'/cacert.pem');

大功告成

（本人验证未通过。。。报错信息为：SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed）

如果对此感兴趣的话可以参看国外一大神文章。

https://www.sodocs.net/doc/55145763.html,/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected -sites/

为了防止某天该文章被Q今复制过来。内容如下：

Using cURL in PHP to access HTTPS (SSL/TLS) protected sites

From PHP, you can access the useful cURL Library (libcurl) to make requests to URLs using a variety of protocols such as HTTP, FTP, LDAP and even Gopher. (If you’ve spent time on the *nix command line, most environments also have the curl command available that uses the libcurl library)

In practice, however, the most commonly-used protocol tends to be HTTP, especially when usingPHP for server-to-server communication. Typically this involves accessing another web server as part of a web service call, using some method such as XML-RPC or REST to query a resource. For example, Delicious offers a HTTP-based API to manipulate and read a user’s posts. However, when trying to access a HTTPS resource (such as the delicious API), there’s a little more configuration you have to do before you can get cURL working right in PHP.

The problem

If you simply try to access a HTTPS (SSL or TLS-protected resource) in PHP using cURL, you’re likely to run into some difficulty. Say you have the following code: (Error handling omitted for brevity)

// Initialize session and set URL.

$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url);

// Set so curl_exec returns the result instead of outputting it.

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

// Get the response and close the channel.

$response = curl_exec($ch);

curl_close($ch);

If $url points toward an HTTPS resource, you’re likely to encounter an error like the one below:

Failed: Error Number: 60. Reason: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The problem is that cURL has not been configured to trust the server’s HTTPS certificate. The concepts of certificates and PKI revolves around the trust of Certificate Authorities (CAs), and by default, cURL is setup to not trust any CAs, thus it won’t trust any web server’s certificate. So why don’t you have problems visiting HTTPs sites through your web browser? As it happens, the browser developers were nice enough to include a list of default CAs to trust, covering most situations, so as long as the website operator purchased a certificate from one of these CAs.

The quick fix

There are two ways to solve this problem. Firstly, we can simply configure cURL to accept any server(peer) certificate. This isn’t optimal from a security point of view, but if you’re not passing sensitive information back and forth, this is probably alright. Simply add the following line before calling curl_exec():

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

This basically causes cURL to blindly accept any server certificate, without doing any verification as to which CA signed it, and whether or not that CA is trusted. If you’re at all concerned about the data you’re passing to or receiving from the server, you’ll want to enable this peer verification properly. Doing so is a bit more complicated.

The proper fix

The proper fix involves setting the CURLOPT_CAINFO parameter. This is used to point towards a CA certificate that cURL should trust. Thus, any server/peer certificates issued by this CA will also be trusted. In order to do this, we first need to get the CA certificate. In this example, I’ll be using the https://https://www.sodocs.net/doc/55145763.html,/ server as a reference.

First, you’ll need to visit the URL with your web browser in order to grab the CA certificate. Then, (in Firefox) open up the security details for the site by double-clicking on the padlock icon in the lower right corner:

Then click on “View Certificate”:

Bring up the “Details” tab of the cerficates page, and select the certificate at the top of the hierarchy. This is the CA certificate.

Then click “Export”, and save the CA certificate to your selected location, making sure to select the X.509 Certificate (PEM) as the save type/format.

Now we need to modify the cURL setup to use this CA certificate, with CURLOPT_CAINFO set to point to where we saved the CA certificate file to.

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);

curl_setopt($ch, CURLOPT_CAINFO, getcwd() .

"/CAcerts/BuiltinObjectToken-EquifaxSecureCA.crt");

The other option I’ve included, CURLOPT_SSL_VERIFYHOST can be set to the following integer values:

0: Don’t check the common name (CN) attribute

1: Check that the common name attribute at least exists

2: Check that the common name exists and that it matches the host name of the server If you have CURLOPT_SSL_VERIFYPEER set to false, then from a security perspective, it doesn’t really matter what you’ve set CURLOPT_SSL_VERIFYHOST to, since without peer

certificate verification, the server could use any certificate, including a self-signed one that was guaranteed to have a CN that matched the server’s host name. So this setting is really only relevant if you’ve enabled certificate verification.

This ensures that not just any server certificate will be trusted by your cURL session. For example, if an attacker were to somehow redirect traffic from https://www.sodocs.net/doc/55145763.html, to their own server, the cURL session here would not properly initialize, since the attacker would not have access to a server certificate (i.e. would not have the private key) trusted by the CA we added. These steps effectively export the trusted CA from the web browser to the cURL configuration.

More information

If you have the CA certificate, but it is not in the PEM format (i.e. it is in a binary or DER format that isn’t Base64-encoded), you’ll need to use something like OpenSSL to convert it to the PEM format. The exact command differs depending on whether you’re converting from PKCS12 or DER format.

There is a CURLOPT_CAPATH option that allows you to specify a directory that holds multiple CA certificates to trust. But it’s not as simple as dumping every single CA certificate in this directory. Instead, they CA certificates must be named properly, and the OpenSSL c_rehashutility can be used to properly setup this directory for use by cURL. https://www.sodocs.net/doc/55145763.html,/ainiaa/archive/2011/11/08/2241385.html

本文转载于天津网站建设-文率科技技术总监韩文博微博，

https://www.sodocs.net/doc/55145763.html,/s/blog_6a48815b0102vksj.html。

IIS架构与HTTP请求处理流程

****************************************************************** ******************************************************************* Windows操作系统中的IIS负责提供互联网服务，一台运行了IIS的计算机可以看成是一台Web服务器。 Windows XP SP2 中IIS主版本号为5，Windows 2003 Server为6，Vista和Windows Server 2008为7。对于Windows 2003 Server，其默认支持的https://www.sodocs.net/doc/55145763.html,版本为1.1，因此必须单独安装.NET Framework 2.0以上版本[1]。 目前，IIS 6是使用最为广泛的版本，IIS 5已基本不在Web服务器上部署， IIS 6与IIS 5相比在系统架构上有着较大的差异，IIS 7与IIS 6相比，基本架构并没有根本性的变化，但在许多方面有新的增强和改进。本书选择IIS 6/7进行介绍，大部分内容也适合于IIS 5，但IIS 5一些已过时的特性就不介绍了。 首先，我们来仔细分辨一下三个很容易混淆的基本概念。 8.1.1网站、Web应用程序和虚拟目录 在IIS中可以创建网站、Web 应用程序和虚拟目录，以便与计算机网络上的用户共享信息。“网站”、“Web 应用程序”和“虚拟目录”这三个概念的关系如图 8?1所示。 图 8?1 网站，应用程序与虚拟目录 简而言之，一个“网站（Web Site）”包含一个或多个“ Web 应用程序（Web Application）”，一个Web 应用程序包含一个或多个“虚拟目录（Virtual Directory）”，而虚拟目录则映射到 Web 服务器或远程计算机上的物理目录。 图 8?2所示为运行IIS 7的一个Web服务器。 图 8?2 IIS 7中的网站，应用程序与虚拟目录 图 8?2中可以清楚地看到此Web服务器上有两个“网站”：Default Web Site和NewWebSite，其中Default Web Site网站中有三个“Web 应用程序”：HappyBookShopService、HappyBookShopWebSite和OnlineAlbum。而HappyBookShopWebSite应用程序下的每一个子文件夹都是一个“虚拟目录”。最顶层的虚拟目录称为“根虚拟目录”，图8?2中Web应用程序HappyBookShopWebSite的根虚拟目录为“/HappyBookShopWebSite”。

HTTP请求报头详解

HTTP头字段包括4类： general-header ; request-header ; response-header ; entity-header . ********************************************************************* ********** General Header Fields ============================= general header是request、response都可用的, 但是不能用于entity. －－Cache-Control －－Connection －－Date －－Pragma －－Trailer －－Transfer-Encoding －－Upgrade －－Via －－Warning ********************************************************************* ********** Request Header Fields ====================== request-header fields 允许客户端传递关于request和客户端的附加信息到服务端， －－Accept －－Accept-Charset －－Accept-Encoding －－Accept-Language －－Authorization －－Expect －－From －－Host －－If-Match －－If-Modified-Since －－If-None-Match －－If-Range －－If-Unmodified-Since

http协议请求响应报文格式及状态码详解

HTTP协议报文格式 HTTP协议（Hypertext Transfer Protocol――超文本传输协议）浏览器端（客户端）向WEB 服务器端访问页面的过程和HTTP协议报文的格式。 基于HTTP协议的客户机访问包括4个过程，分别是建立TCP套接字连接、发送HTTP请求报文、接收HTTP应答报文和关闭TCP套接字连接： 1. 创建TCP套接字连接 客户端与WEB服务器创建TCP套接字连接，其中WEB端服务器的地址可以通过域名解析确定，WEB端的套接字侦听端口一般是80。 2. 发送HTTP请求报文 客户端向WEB服务端发送请求报文，HTTP协议的请求报文格式为： 请求消息= 请求行（实体头信息）CRLF[实体内容] 请求行= 方法URL HTTP版本号CRLF 方法= GET|HEAD|POST|扩展方法 URL = 协议名称＋宿主名＋目录与文件名 其中"CRLF"表示回车换行。 "请求行"中的"方法"描述了对指定资源执行的动作，常用的方法"GET"、"HEAD"和"POST"等3种，它们的含义如表15-8所示： 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾 与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 表15-8 HTTP请求方法

HTTP请求方法及响应码详解(http get post head)

HTTP是Web协议集中的重要协议，它是从客户机/服务器模型发展起来的。客户机/服务器是运行一对 相互通信的程序，客户与服务器连接时，首先，向服务器提出请求，服务器根据客户的请求，完成处理 并给出响应。浏览器就是与Web服务器产生连接的客户端程序，它的端口为TCP的80端口，。浏览器 与Web 服务器之间所遵循的协议就是HTTP。 HTTP的早期版本为HTTP/0.9，它适用于各种数据信息的简洁快速协议，但是其远不能满足日益发展各 种应用的需要。但HTTP/0.9作为HTTP协议具有典型的无状态性：每个事务都是独立进行处理的，当 一个事务开始就在客户与服务器之间建立一个连接，当事务结束时就释放这个连接。HTTP/0.9包含Simple-Request&Simple-Responsed的报文结构。但是客户无法使用内容协商，所以服务器也无法 返回实体的媒体类型。 1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不断丰富和发展中，HTTP/1.0成为最重要 的面向事务的应用层协议。该协议对每一次请求/响应，建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。其缺点是仍会发生下列问题：对用户请求响应慢、网络拥 塞严重、安全性等。 1997年形成的HTTP/1.1，也就是现在普遍使用的协议，在持续连接操作机制中实现流水方式，即客户 端需要对同一服务器发出多个请求时，其实现在多数的网页都是有多部分组成（比如多张图片），可用 流水线方式加快速度，流水机制就是指连续发出多个请求并等到这些请求发送完毕，再等待响应。这样 就大大节省了单独请求对响应的等待时间，使我们得到更快速的浏览。 另外，HTTP/1.1服务器端处理请求时按照收到的顺序进行,这就保证了传输的正确性。当然，服务器端 在发生连接中断时，会自动的重传请求，保证数据的完整性。 HTTP/1.1还提供了身份认证、状态管理和Cache缓存等机制。这里，我想特别提一下关于HTTP/1.1 中的Cache缓存机制对 HTTP/1.0的不足之处的改进，它严格全面，既可以减少时间延迟、又节省了带宽。HTTP/1.1采用了内容协商机制，选择最合适的用户的内容表现形式。 现在，很多地方都有用到的虚拟主机技术在HTTP/1.1中也可以实现。所谓的虚拟主机技术，就是同一 主机地址实际对应多台主机。通俗的讲，当你同时在一个网站申请两个主页时，用协议分析仪可以发现 其实这两个主页对应的是同一个IP地址。这样用多台完全相同的机器形成WWW服务器就可以提高处 理的吞吐量。 传统的解决方案是改造域名服务器使其可以根据一定的算法将同一域名解释成不同的IP地址。分别对应 虚拟主机的每台机器，其缺点是要求每台机器占用完全独立的IP地址，这与IP地址的缺乏是相矛盾的。HTTP/1.1提供的解决方案在HTTP协议自身中加入了指定不同主机的功能，从而多台主机可以共享一个IP地址，既提高了性能又便于管理。 因为HTTP/1.1是Internet现行的标准协议，这里详细介绍其相关语法。 首先，HTTP/1.1格式可写为： 其中请求方法是请求一定的Web页面的程序或用于特定的URL。可选用下列几种： GET：请求指定的页面信息，并返回实体主体。 HEAD：只请求页面的首部。 POST：请求服务器接受所指定的文档作为对所标识的URI的新的从属实体。 PUT：从客户端向服务器传送的数据取代指定的文档的内容。

抓包实验

：利用Wireshark软件进行数据包抓取 1.3.2 抓取一次完整的网络通信过程的数据包实验 一，实验目的： 通过本次实验，学生能掌握使用Wireshark抓取ping命令的完整通信过程的数据包的技能，熟悉Wireshark软件的包过滤设置和数据显示功能的使用。 二，实验环境： 操作系统为Windows 7,抓包工具为Wireshark. 三，实验原理： ping是用来测试网络连通性的命令，一旦发出ping命令，主机会发出连续的测试数据包到网络中，在通常的情况下，主机会收到回应数据包，ping采用的是ICMP协议。 四，验步骤： 1.确定目标地址：选择https://www.sodocs.net/doc/55145763.html,作为目标地址。 2.配置过滤器：针对协议进行过滤设置，ping使用的是ICMP协议，抓包前使用捕捉过滤器，过滤设置为icmp,如图 1- 1

图 1-1 3.启动抓包：点击【start】开始抓包，在命令提示符下键入ping https://www.sodocs.net/doc/55145763.html,, 如图 1-2

图 1-2 停止抓包后，截取的数据如图 1-3 图 1-3 4，分析数据包：选取一个数据包进行分析，如图1- 4

图1-4 每一个包都是通过数据链路层DLC协议，IP协议和ICMP协议共三层协议的封装。DLC协议的目的和源地址是MAC地址，IP协议的目的和源地址是IP地址，这层主要负责将上层收到的信息发送出去，而ICMP协议主要是Type和Code来识别，“Type:8,Code：0”表示报文类型为诊断报文的请求测试包，“Type:0,Code:0”表示报文类型为诊断报文类型请正常的包。ICMP提供多种类型的消息为源端节点提供网络额故障信息反馈，报文类型可归纳如下： （1）诊断报文（类型：8，代码0；类型：0代码：0）； (2）目的不可达报文（类型：3，代码0-15）； （3）重定向报文（类型：5，代码：0--4）； （4）超时报文（类型：11，代码：0--1）； （5）信息报文（类型：12--18）。

http协议交互过程

竭诚为您提供优质文档/双击可除 http协议交互过程 篇一：wireshake抓包分析tcp与http过程详解 http协议报文格式详解 在我们日常生活中最常见的应用环境就是上网浏览网页，很多上班族到办公室的第一件事就是打开电脑，而开机后的第一件事就是打开ie、Firefox、myie、greenbrowser、opera等浏览器时，做的第一件事就是浏览一下例如.cn,的新闻，而这种简单的应用操作，完成的交互过程就是一个典型的http协议的应用过程。 http是基于tcp的连接，因此，建立http连接必须经过tcp的过程，tcp的建立过程是3次握手的过程。然后就是http过程，http只有两种报文，请求和应答报文。完成http过程后，3次断开tcp连接。 http tcp的第一阶段 http开始之前先3次握手，第一阶段就是客户向服务器发送同步请求，flag字段的syn位置1。 第二阶段

第二阶段就是服务器向客户回复一个ack包，其中Flag 字段的syn位和ack字段置1。 tcp的第三阶段： tcp的第三阶段是客户向服务器发送ack，至此，tcp的3次握手结束 tcp三次握手结束之后就是http请求 客户发出http请求之后，服务器收到请求发送ack： 服务器发送应答报文 篇二：http协议分析报告实例 http协议分析 1实验目的 分析http协议报文首部格式，理解http协议工作过程2实验内容 截获http报文，分析http协议报文首部格式，学习http 协议工作过程。3实验原理 超文本传送协议http（hypertexttransferprotocol）,是万维网客户程序与万维网服务器程序之间的交互所要严 格遵守的协议。http是一个应用层协议，它使用tcp连接进行可靠的传送。对于万维网站点的访问要使用的http协议。 http的uRl的一般形式是：http://:/ www采用b/s结构，客户使用浏览器在uRl栏中输入http 请求，即输入对方服务器的地址，向web服务器提出请求。

运行时创建HTTP请求及请求的处理

1、发起请求 下面这个方法的作用就是接收要发送的数据及数据要发送到的URL，然后返回响应数据 protected string SendRequest(string data,string url) { WebRequest req = WebRequest.Create(url); req.Method = "POST"; req.ContentType = "application/x-www-form-urlencoded"; byte[] sendBytes = Encoding.UTF8.GetBytes(data); req.ContentLength = sendBytes.Length; Stream reqStream = req.GetRequestStream(); reqStream.Write(sendBytes, 0, sendBytes.Length); reqStream.Close(); WebResponse res = req.GetResponse(); Stream resStream = res.GetResponseStream(); StreamReader sr = new StreamReader(resStream, Encoding.UTF8); string resData = sr.ReadToEnd(); sr.Close(); resStream.Close(); return resData; } 使用示例： protected void btnSubscribe_Click(object sender, EventArgs e) { string FileName = Server.MapPath("订购.xml");

HTTPS请求工具类汇总

HTTPS请求 package com.sunzk.dreamsunlight.weixin.util; import java.io.BufferedReader; import java.io.InputStream; import java.io.InputStreamReader; import java.io.OutputStream; import https://www.sodocs.net/doc/55145763.html,.ConnectException; import https://www.sodocs.net/doc/55145763.html,.URL; import https://www.sodocs.net/doc/55145763.html,.ssl.HttpsURLConnection; import https://www.sodocs.net/doc/55145763.html,.ssl.SSLContext; import https://www.sodocs.net/doc/55145763.html,.ssl.SSLSocketFactory; import https://www.sodocs.net/doc/55145763.html,.ssl.TrustManager; import net.sf.json.JSONException; import net.sf.json.JSONObject; import org.apache.log4j.Logger;

import com.sunzk.dreamsunlight.weixin.certificate.MyX509 TrustManager; import com.sunzk.dreamsunlight.weixin.model.Menu; import com.sunzk.dreamsunlight.weixin.token.AccessToken; /** * * @ClassName: WeiXinHttpsUtil * * @Description: TODO(微信HTTPS请求工具类) * * @author sunzk-dreamsunlight-QQ(1131341075) * * @date 2016-11-14 上午10:05:56 * */ public class WeiXinHttpsUtil {

使用wireshark分析HTTPS流程的建立

使用wireshark分析HTTPS流程的建立

使用wireshark分析HTTPS流程的建立 摘要: https流程 一、概要 为了网站以及用户的安全性，现在很多的网站都是https，大家都知道tcp通过三次握手建立连接，并且还有很多的同学对https连接建立的流程不太明白，包括我自己，通过借助于wireshark这种抓包工具，我们可以尝试着了解一下大概的流程。 （图1） 本图是客户端（10.0.45.103）访问服务端（114.215.88.85）通过wireshark 抓包显示出来的双方交互数据，访问是通过https访问服务器上的一台nginx 服务器服务。请关注第一列的No。下文中很多时候会用no表示一次交互。 图中可以很明显的看出tcp的三次握手以及之后的TLS加密流程的建立。二、tcp的三次握手 通过流程图可以看出（也可以看图1 的19368到19370这三个编号），首先客户端向服务端发起一个SYN的请求，序号(Seq)为0，确认号（ACK）也为0，这代表是本次是由客户端发起的首次请求。本次请求的数据长度为0 然后服务端给客户端响应，此时服务端的Seq也是0，值得是服务端的第一回应，并且给客户端说，你的请求我已经收到了（ACK=1），

最后返还给客户端以后，客户端的序号+1，并且对服务端的响应做出确认，最后回给服务端，此时ACK=1，Seq=1 tcp的握手过程建立成功。 三、ssl连接的建立 通过以上可以看出，SSL也是建立在TCP的基础上的，经过tcp的三次握手，接下来才是加密信道的建立。 客户端和服务端建立安全连接大致经过以下几个步骤 1.客户端：ClientHello 2.服务端：Server Hello，Server certificate，Server Exchange，Server Hello Done 3.客户端：client Exchange 4.客户端：Application Data 5.服务端：New Session 6.服务端：Application Data 接下来看这几个步骤中具体的每一个步骤传输的内容 ClientHello client首先给服务端打招呼，对服务端说hello 应用层没什么特别的

http请求处理流程(讲的很清楚)

.NET平台处理HTTP请求 .NET平台处理HTTP请求的过程大致如下： 1、IIS得到一个请求；，。 2、查询脚本映射扩展，然后把请求映射到文件 3、代码进入工作者进程(IIS5里是；IIS6里是，工作者进程也叫辅助进程； 4、 .NET运行时被加载； 5、非托管代码调用()方法； 6、每一个请求调用一个IsapiWorkerRequest； 7、使用WorkerRequest调用()方法； 8、通过传递进来的WorkerRequest创建一个HttpContext对象 9、通过把上下文对象作为参数传递给()，然后调用该方法，从应用程序池中获取一个HttpApplication实例； 10、调用()，启动管道事件序列，钩住模块和处理器； 11、调用，开始处理请求； 12、触发管道事件； 13、调用HTTP处理器和ProcessRequest方法； 14、把返回的数据输出到管道，触发处理请求后的事件。 当客户端向Web服务器请求一个页面文件时，这个HTTP请求会被进程截获(WWW服务)，它判断文件后缀，如果是*.aspx、*.asmx等，就把这个请求转交给，而则会通过一个Http PipeLine的管道，将这个HTTP请求发送给进程，当这个HTTP请求进入进程之后， framework就会通过HttpRuntime来处理这个HTTP 请求，处理完毕后将结果返回给客户端。 当一个HTTP请求被送入到HttpRuntime之后，这个HTTP请求通过HTTP管道(HttpRuntime是HTTP管道的入口)被送入到一个被称之为HttpApplication Factory的一个容器当中，而这个容器会给出一个HttpApplication实例来处理传递进来的HTTP请求，同时HttpApplication实例会创建一个HttpContext对象来记录HTTP请求的上下文，而后这个HTTP请求会依次进入到如下几个容器中：HttpModule --> HttpHandler Factory --> HttpHandler当系统内部的HttpHandler的ProcessRequest方法处理完毕之后，整个Http Request就被处理完成了。 如果想在中途截获一个HttpRequest并做些自己的处理，就应该在HttpRuntime运行时内部来做到这一点，确切的说时在HttpModule这个容器中做到这个的。 过程详解： 从本质上讲，主要是由一系列的类组成，这些类的主要目的就是将Http请求转变为对客户端的响应。HttpRuntime类是的一个主要入口，它有一个ProcessRequest方法，这个方法以一个 HttpWorkerRequest 类作为参数。HttpRuntime类几乎包含着关于单个Http请求的所有信息：所请求的文件、服务器端变量、QueryString、Http头信息等等。使用这些信息来加载、运行正确的文件，并且将这个请求转换到输出流中，一般来说，就是HTML页面；二般来说，也可以是张图片^_^。

http请求响应过程

http请求与响应过程 （1）请求方法URI协议/版本 请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1 以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。 根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1目前支持7种请求方法：GET、POST、HEAD、OPTIONS、 PUT、DELETE和TARCE。 GET 请求获取由Request-URI所标识的资源。 POST 在Request-URI所标识的资源后附加新的数据。 HEAD 请求获取由Request-URI所标识的资源的响应消息报头。 OPTIONS 请求查询服务器的性能，或查询与资源相关的选项和需求。 PUT 请求服务器存储一个资源，并用Request-URI作为其标识。 DELETE 请求服务器删除由Request-URI所标识的资源。 TRACE 请求服务器回送收到的请求信息，主要用语测试或诊断。 在Internet应用中，最常用的方法是GET和POST。 URI完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最 后，协议版本声明了通信过程中使用HTTP的版本。 （2）服务器响应状态码 状态代码： 状态代码由3位数字组成，表示请求是否被理解或被满足。 状态描述： 状态描述给出了关于状态代码的简短的文字描述。 状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。 第一个数字有五种可能的取值： - 1xx: 指示信息—表示请求已接收，继续处理。 - 2xx: 成功—表示请求已经被成功接收、理解、接受。 - 3xx: 重定向—要完成请求必须进行更进一步的操作。 - 4xx: 客户端错误—请求有语法错误或请求无法实现。 - 5xx: 服务器端错误—服务器未能实现合法的请求。 状态代码状态描述说明 200 OK --客户端请求成功 400 Bad Request --由于客户端请求有语法错误，不能被服务器所理解。 401 Unauthonzed --请求未经授权，请求身份认证。这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden --服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因

https请求的抓包方法

对于https协议的接口的抓包方法 一、使用fiddler 1.使用fiddler对浏览器访问的https接口抓包 默认设置下的fiddler是不能解密https协议的请求的内容的，在fiddler上抓到的https 协议的请求都是如下图所示，但是看不到其中的传参以及返回结果的内容： 如果想要用fiddler抓到浏览器访问的https接口，需要在fiddler做如下设置： a)进入菜单栏，Tools->Fiddler Options： b)切换到https选项卡，勾选如下选项： c)按照上面步骤勾选后，会弹出如下提示框，提示意思大概就是fiddler会生成 一个唯一的根证书，我们要配置Windows，使Windows信任这个CA证书，

所以点击Yes即可： d)点击Yes之后，Windows会马上弹出下面的弹窗，我们点击“是”，就能将 DO_NOT_TRUST_FiddlerRoot这个由fiddler生成的CA证书导入到浏览器，也就 完成了上面C步骤所述的配置Windows，使Windows信任这个CA证书的步 骤： 完成了上面的配置后，即可以在浏览器发起一个https协议的请求： 此时可以在fiddler抓到这个请求，并能看到传参内容和返回的内容

返回的内容： 2.使用fiddler对app访问的https接口抓包 首先要先在fiddler进行设置，步骤与上面的一样，但是不用导入证书到浏览器，这里不再赘述。 Android： 要使用fiddler抓到app发出的https请求，需要在app端安装fiddler生成的CA证书，在Android的app端安装fiddler生成的CA证书步骤如下： a)设置手机代理服务器，代理到自己的电脑：

有关http请求返回值的说明

2xx 成功 200 正常;请求已完成。 201 正常;紧接 POST 命令。 202 正常;已接受用于处理，但处理尚未完成。 203 正常;部分信息—返回的信息只是一部分。 204 正常;无响应—已接收请求，但不存在要回送的信息。 3xx 重定向 301 已移动—请求的数据具有新的位置且更改是永久的。 302 已找到—请求的数据临时具有不同 URI。 303 请参阅其它—可在另一 URI 下找到对请求的响应，且应使用 GET 方法检索此响应。 304 未修改—未按预期修改文档。 305 使用代理—必须通过位置字段中提供的代理来访问请求的资源。 306 未使用—不再使用;保留此代码以便将来使用。 4xx 客户机中出现的错误 400 错误请求—请求中有语法问题，或不能满足请求。 401 未授权—未授权客户机访问数据。 402 需要付款—表示计费系统已有效。 403 禁止—即使有授权也不需要访问。 404 找不到—服务器找不到给定的资源;文档不存在。 407 代理认证请求—客户机首先必须使用代理认证自身。 410 请求的网页不存在(永久); 415 介质类型不受支持—服务器拒绝服务请求，因为不支持请求实体的格式。 5xx 服务器中出现的错误 500 内部错误—因为意外情况，服务器不能完成请求。 501 未执行—服务器不支持请求的工具。 502 错误网关—服务器接收到来自上游服务器的无效响应。 503 无法获得服务—由于临时过载或维护，服务器无法处理请求。 100系列码 从100到199范围的HTTP状态码是信息报告码。基于各种原因考虑，大多数情况下我们是很少看见这些代码的。首先，如果一个浏览器尝试访问一个网站，而网站返回这些代码时，它们往往都不会显示在屏幕上。它们只是浏览器使引用的内部码。另外，这些代码不常见的另外一个原因是起初HTTP标准不允许使用这一范围的状态码。就其本身而言，它们也一直没有被广泛地使用。 200系列码 从 200到299范围的状态码是操作成功代码。同样的，在正常的Web上网中，你也很可能不曾在屏幕上看到这些代码。相反的，这些代码是在浏览器内部使用的，用以确认操作成功确认和当前请求状态。虽然这些代码通常不显示，但是有一些故障排除工具能够读到它们，就像和其它大多数的HTTP状态码一样，它们在错误诊断过程中是非常有用的。

HTTP客户端的设计与实现

一、实验目的和要求 1、实验目的 HTTP客户端程序的功能是给出一个URL，要求程序能够获得指定URL所指向的内容，对于获得内容不必做进一步的处理，只打印HTML代码即可 ●通过HTTP客户端程序使学生掌握网络编程的基本知识和基 本技能； ●使学生掌握HTTP协议的常用命令； ●通过跟踪运行java网络包，使学生了解网络编程实现的细节。 2、实验要求 本实验要求实现一个简单的HTTP客户端，具体内容及要求如下： ●分析HTTP客户端程序的功能，要求能根据给定的URL，获 得URL指向的资源，对于资源的内容可以不做任何的处理， 直接打印即可； ●实现HTTP客户端程序； ●跟踪运行java网络包。 二、系统技术路线和运行环境 1、技术路线： 本系统采用Java语言开发，可以适应几乎所有支持JVM的操作系统。同时Java语言在网络领域的特殊优势，使得它所提供的类库中包含了较为丰富的网络编程API，可以使开发人员方便地开发网络通信类应用程序。

其次还采用了Tomcat6.0与jsp相结合的web建设、使得该系统能够更好的符合实验的要求和标准。 2、系统运行环境： ●硬件环境： PC机一台 ●软件环境： 操作系统：Windows XP、Tomcat6.0、jdk6.0、eclipse等 三、程序的逻辑框图 程序流逻辑框图能够帮助我们更好的熟悉和了解该系统的运行过程，本系统的一些逻辑框图如下所示：

四、程序源代码 1、基于URL的HttpClient.java程序代码如下：import java.awt.*; import java.awt.event.*; import java.io.*; import https://www.sodocs.net/doc/55145763.html,.*; import javax.swing.*; public class HttpClient extends JApplet implements ActionListener { //创建一个按钮来点击事件 private JButton jbtView = new JButton("View"); //文本字段来接收文件的名字 private JTextField jtfURL = new JTextField(12);

http 使用curl发起https请求

http 使用curl发起https请求 今天一个同事反映，使用curl发起https请求的时候报错：“SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed” 很明显，验证证书的时候出现了问题。 使用curl如果想发起的https请求正常的话有2种做法： 方法一、设定为不验证证书和host。 在执行curl_exec()之前。设置option $ch = curl_init(); ...... curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE); 方法二、设定一个正确的证书。 本地ssl判别证书太旧，导致链接报错ssl证书不正确。 我们需要下载新的ssl 本地判别文件 http://curl.haxx.se/ca/cacert.pem 放到程序文件目录 curl 增加下面的配置 curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,true); ; curl_setopt($ch,CURLOPT_CAINFO,dirname(__FILE__).'/cacert.pem'); 大功告成 （本人验证未通过。。。报错信息为：SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed） 如果对此感兴趣的话可以参看国外一大神文章。 https://www.sodocs.net/doc/55145763.html,/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected -sites/ 为了防止某天该文章被Q今复制过来。内容如下： Using cURL in PHP to access HTTPS (SSL/TLS) protected sites From PHP, you can access the useful cURL Library (libcurl) to make requests to URLs using a variety of protocols such as HTTP, FTP, LDAP and even Gopher. (If you’ve spent time on the *nix command line, most environments also have the curl command available that uses the libcurl library) In practice, however, the most commonly-used protocol tends to be HTTP, especially when usingPHP for server-to-server communication. Typically this involves accessing another web server as part of a web service call, using some method such as XML-RPC or REST to query a resource. For example, Delicious offers a HTTP-based API to manipulate and read a user’s posts. However, when trying to access a HTTPS resource (such as the delicious API), there’s a little more configuration you have to do before you can get cURL working right in PHP. The problem If you simply try to access a HTTPS (SSL or TLS-protected resource) in PHP using cURL, you’re likely to run into some difficulty. Say you have the following code: (Error handling omitted for brevity) // Initialize session and set URL. $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); // Set so curl_exec returns the result instead of outputting it. curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); // Get the response and close the channel. $response = curl_exec($ch);

HttpRuntime请求处理周期

IIS 5 的https://www.sodocs.net/doc/55145763.html, 请求处理过程 对图的解释： IIS 5.x 一个显著的特征就是Web Server 和真正的https://www.sodocs.net/doc/55145763.html, Application 的分离。作为Web Server 的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的https://www.sodocs.net/doc/55145763.html, Application aspnet_wp 的Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。 IIS6 的https://www.sodocs.net/doc/55145763.html, 请求处理过程 对图的解释： IIS 5.x 是通过InetInfo.exe 监听Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对 Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：

注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。 在User Mode下，http.sys接收到一个基于aspx 的http request，然后它会根据IIS中的Metabase 查看该基于该Request 的Application 属于哪个Application Pool，如果该Application Pool不存在，则创建之。否则直接将request 发到对应Application Pool 的Queue中。每个Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在worker process 初始化的时候，加载 https://www.sodocs.net/doc/55145763.html, ISAPI，https://www.sodocs.net/doc/55145763.html, ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的Create方法为Application 创建一个Application Domain；通过ISAPIRuntime 的ProcessRequest处理Request，进而将流程进入到https://www.sodocs.net/doc/55145763.html, Http Runtime Pipeline。 IIS 7的https://www.sodocs.net/doc/55145763.html, 请求处理过程 IIS7 站点启动并处理请求的步骤如下图： 步骤1 到6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。 上图的8个步骤分别如下： 1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。 2、HTTP.sys contacts WAS to obtain information from the configuration store. 3、WAS 向配置存储中心请求配置信息。applicationHost.config。 4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。 5、WWW 服务使用配置信息去配置HTTP.sys 处理策略。 6、WAS starts a worker process for the application pool to which the request was made. 7、The worker process processes the request and returns a response to HTTP.sys. 8、客户端接受到处理结果信息。 W3WP.exe 进程中又是如果处理得呢？？IIS 7 的应用程序池的托管管道模式分两种：经典和集成。这两种模式下处理策略各不相通。 本文作者：郭红俊https://www.sodocs.net/doc/55145763.html,/ghj IIS 6 以及IIS7 经典模式的托管管道的架构 在IIS7之前，https://www.sodocs.net/doc/55145763.html, 是以IIS ISAPI extension 的方式外加到IIS，其实包括ASP 以及PHP，也都以相同的方式配置（PHP 在IIS 采用了两种配置方式，除了IIS ISAPI extension 的方式，也包括了CGI 的方式，系统管理者能选择PHP 程序的执行方式），因此客户端对IIS 的HTTP 请求会先经由IIS 处理，然后IIS 根据要求的内容类型，如果是HTML 静态网页就由IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的IIS ISAPI extension；如果要求的内容类型是https://www.sodocs.net/doc/55145763.html,，就分派给负责处理https://www.sodocs.net/doc/55145763.html, 的IIS ISAPI extension，也就是aspnet_isapi.dll。下图是这个架构的示意图。 IIS7 应用程序池的托管管道模式经典模式也是这样的工作原理。这种模式是兼容IIS 6 的方式，以减少升级的成本。