python web渗透测试学习2Web应使用交互2访问web工具requests

Requests是Python基于Apache2 Licensed许可证的人性化HTTP库。

Python标准库中urllib2提供了不少HTTP 功能，但API不系统。它有点过时，完成最简单的任务也需要大量工作。

状态码：

import requestspayload= {'url':'https://china-testing.github.io/address.html'}r=requests.get('http://httpbin.org/redirect-to',params=payload)print("Status code:")print("\t *" + str(r.status_code))

执行结果

Status code:     *200

自己设置头：

import requestsmyheaders={'user-agent':'Iphone 6'}r =  requests.post('http://httpbin.org/post',data={'name':'packt'})print(r.url)print('Status code:')print('\t[-]' + str(r.status_code) + '\n')print('Server headers')print('****************************************')for x in r.headers:    print('\t' + x + ' : ' + r.headers[x])print('****************************************\n')print("Content:\n")print(r.text)

执行结果

$ python3 Video-3-headers.py http://httpbin.org/postStatus code:    [-]200Server headers****************************************    Connection : keep-alive    Server : gunicorn/19.8.1    Date : Tue, 17 Jul 2018 22:00:10 GMT    Content-Type : application/json    Content-Length : 340    Access-Control-Allow-Origin : *    Access-Control-Allow-Credentials : true    Via : 1.1 vegur****************************************Content:{"args":{},"data":"","files":{},"form":{"name":"packt"},"headers":{"Accept":"*/*","Accept-Encoding":"gzip, deflate","Connection":"close","Content-Length":"10","Content-Type":"application/x-www-form-urlencoded","Host":"httpbin.org","User-Agent":"python-requests/2.18.4"},"json":null,"origin":"120.229.3.164","url":"http://httpbin.org/post"}

跳转：

import requestsurl='http://httpbin.org/redirect-to'payload = {'url':'https://china-testing.github.io'}req = requests.get(url,params=payload)print("Response code: " + str(req.status_code))for x in req.history:    print(str(x.status_code) + ' : ' + x.url)

执行结果

Response code: 200 * 302 : http://httpbin.org/redirect-to?url=https%3A%2F%2Fchina-testing.github.io

可爱的python测试开发库 请在github上点赞，谢谢！
python中文库文档汇总
接口自动化性能测试线上培训大纲
python测试开发自动化测试数据分析人工智能自学每周一练
[雪峰磁针石博客]python3标准库-中文版

更多内容请关注 雪峰磁针石：简书

• 技术支撑qq群： 144081101(后期会录制视频存在该群群文件) 591302926 567351477 钉钉免费群：21745728

• 道家技术-手相手诊看相中医等钉钉群21734177 qq群：391441566 184175668 338228106 看手相、面相、舌相、抽签、体质识别。服务费50元每人次起。请联络钉钉或者者微信pythontesting

image.png

HTTP状态码

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

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

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

1xx消息

这一类型的状态码，代表请求已被接受，需要继续解决。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。因为HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些实验条件下，服务器禁止向此类用户端发送1xx响应。 这些状态码代表的响应都是信息性的，标示用户应该采取的其余行动。

• 100 Continue
  服务器已经接收到请求头，并且用户端应继续发送请求主体（在需要发送身体的请求的情况下：例如，POST请求），或者者假如请求已经完成，忽略这个响应。服务器必需在请求完成后向用户端发送一个最终响应。要使服务器检查请求的头部，用户端必需在其初始请求中发送Expect: 100-continue作为头部，并在发送正文之前接收100 Continue状态代码。响应代码417期望失败表示请求不应继续。

• 101 Switching Protocols
  服务器已经了解了用户端的请求，并将通过Upgrade消息头通知用户端采使用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。
  只有在切换新的协议更有好处的时候才应该采取相似措施。例如，切换到新的HTTP版本（如HTTP/2）比旧版本更有优势，或者者切换到一个实时且同步的协议（如WebSocket）以传送利使用此类特性的资源。

• 102 Processing（WebDAV；RFC 2518）
  WebDAV请求可能包含许多涉及文件操作的子请求，需要很长时间才能完成请求。该代码表示??服务器已经收到并正在解决请求，但无响应可使用。这样可以防止用户端超时，并假设请求丢失。

2xx成功

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

• 200 OK
  请求已成功，请求所希望的响应头或者数据体将随此响应返回。实际的响应将取决于所用的请求方法。在GET请求中，响应将包含与请求的资源相对应的实体。在POST请求中，响应将包含形容或者操作结果的实体。

• 201 Created
  请求已经被实现，而且有一个新的资源已经依据请求的需要而创立，且其URI已经随Location头信息返回。如果需要的资源无法及时创立的话，应当返回’202 Accepted’。

• 202 Accepted
  服务器已接受请求，但尚未解决。最终该请求可能会也可能不会被执行，并且可能在解决发生时被禁止。

• 203 Non-Authoritative Information（自HTTP / 1.1起）
  服务器是一个转换代理商服务器（transforming proxy，例如网络加速器），以200 OK状态码为起源，但回应了原始响应的修改版本。

• 204 No Content
  服务器成功解决了请求，没有返回任何内容。

• 205 Reset Content
  服务器成功解决了请求，但没有返回任何内容。与204响应不同，此响应要求请求者重置文档视图。

• 206 Partial Content（RFC 7233）
  服务器已经成功解决了部分GET请求。相似于FlashGet或者者迅雷这类的HTTP 下载工具都是用此类响应实现断点续传或者者将一个大文档分解为多个下载段同时下载。

• 207 Multi-Status（WebDAV；RFC 4918）
  代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

• 208 Already Reported （WebDAV；RFC 5842）
  DAV绑定的成员已经在（多状态）响应之前的部分被列举，且未被再次包含。

• 226 IM Used （RFC 3229）
  服务器已经满足了对资源的请求，对实体请求的一个或者多个实体操作的结果表示。

3xx重定向

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

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

• 300 Multiple Choices
  被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。使用户或者浏览器能够自行选择一个首选的地址进行重定向。
  除非这是一个HEAD请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便使用户或者浏览器从中选择最合适的重定向地址。这个实体的格式由Content-Type定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。
  假如服务器本身已经有了首选的回馈选择，那么在Location中应当指明这个回馈的URI；浏览器可能会将这个Location值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。

• 301 Moved Permanently
  被请求的资源已永久移动到新位置，并且将来任何对此资源的引使用都应该用本响应返回的若干个URI之一。假如可能，拥有链接编辑功能的用户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
  新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
  假如这不是一个GET或者者HEAD请求，那么浏览器禁止自动进行重定向，除非得到使用户确实认，由于请求的条件可能因而发生变化。
  注意：对于某些用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。

• 302 Found
  要求用户端执行临时重定向（原始形容短语为“Moved Temporarily”）。因为这样的重定向是临时的，用户端应当继续向原有地址发送以后的请求。只有在Cache-Control或者Expires中进行了指定的情况下，这个响应才是可缓存的。
  新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
  假如这不是一个GET或者者HEAD请求，那么浏览器禁止自动进行重定向，除非得到使用户确实认，由于请求的条件可能因而发生变化。
  注意：尽管RFC 1945和RFC 2068规范不允许用户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且用GET方式访问在Location中规定的URI，而无视原价请求的方法。因而状态码303和307被增加了进来，使用以明确服务器期待用户端进行何种反应。

• 303 See Other
  对应当前请求的响应可以在另一个URI上被找到，当响应于POST（或者PUT / DELETE）接收到响应时，用户端应该假定服务器已经收到数据，并且应该用单独的GET消息发出重定向。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引使用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。
  新的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
  注意：许多HTTP/1.1版以前的浏览器不能正确了解303状态。假如需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，由于大多数的浏览器解决302响应时的方式恰恰就是上述规范要求用户端解决303响应时应当做的。

• 304 Not Modified
  表示资源未被修改，由于请求头指定的版本If-Modified-Since或者If-None-Match。在这种情况下，因为用户端依然具备以前下载的副本，因而不需要重新传输资源。

• 305 Use Proxy
  被请求的资源必需通过指定的代理商才能被访问。Location域中将给出指定的代理商所在的URI信息，接收者需要重复发送一个单独的请求，通过这个代理商才能访问相应资源。只有原始服务器才能创立305响应。许多HTTP用户端（像是Mozilla和Internet Explorer）都没有正确解决这种状态代码的响应，主要是出于安全考虑。
  注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。

• 306 Switch Proxy
  在最新版的规范中，306状态码已经不再被用。最初是指“后续请求应用指定的代理商”。

• 307 Temporary Redirect
  在这种情况下，请求应该与另一个URI重复，但后续的请求应仍用原始的URI。 与302相反，当重新发出原始请求时，不允许更改请求方法。 例如，应该用另一个POST请求来重复POST请求。

• 308 Permanent Redirect (RFC 7538)
  请求和所有将来的请求应该用另一个URI重复。 307和308重复302和301的行为，但不允许HTTP方法更改。 例如，将表单提交给永久重定向的资源可能会顺利进行。

4xx用户端错误

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

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

• 400 Bad Request
  因为显著的用户端错误（例如，格式错误的请求语法，太大的大小，无效的请求消息或者欺骗性路由请求），服务器不能或者不会解决该请求。

• 401 Unauthorized（RFC 7235）

  相似于403 Forbidden，401语义即“未认证”，即可使用户没有必要的凭据。该状态码表示当前请求需要使用户验证。该响应必需包含一个适使用于被请求资源的WWW-Authenticate信息头使用以讯问使用户信息。用户端可以重复提交一个包含恰当的Authorization头信息的请求。假如当前请求已经包含了Authorization证书，那么401响应代表着服务器验证已经拒绝了那些证书。假如401响应包含了与前一个响应相同的身份验证讯问，且浏览器已经至少尝试了一次验证，那么浏览器应当向使用户展现响应中包含的实体信息，由于这个实体信息中可能包含了相关诊断信息。
  注意：当网站（通常是网站域名）禁止IP地址时，有些网站状态码显示的401，表示该特定地址被拒绝访问网站。

• 402 Payment Required
  该状态码是为了将来可能的需求而预留的。该状态码最初的用意可能被使用作某种形式的数字现金或者在线支付方案的一部分，但几乎没有哪家服务商用，而且这个状态码通常不被用。假如特定开发人员已超过请求的每日限制，Google Developers API会用此状态码。

• 403 Forbidden

  服务器已经了解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。假如这不是一个HEAD请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内形容拒绝的起因。当然服务器也可以返回一个404响应，如果它不希望让用户端取得任何信息。

• 404 Not Found

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

• 405 Method Not Allowed
  请求行中指定的请求方法不能被使用于请求相应的资源。该响应必需返回一个Allow头信息使用以表示出当前资源能够接受的请求方法的列表。例如，需要通过POST呈现数据的表单上的GET请求，或者只读资源上的PUT请求。
  鉴于PUT，DELETE方法会对服务器上的资源进行写操作，因此绝大部分的网页服务器都不支持或者者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。

• 406 Not Acceptable

  请求的资源的内容特性无法满足请求头中的条件，因此无法生成响应实体，该请求不可接受。
  除非这是一个HEAD请求，否则该响应就应当返回一个包含可以让使用户或者者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由Content-Type头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。

• 407 Proxy Authentication Required（RFC 2617）
  与401响应相似，只不过用户端必需在代理商服务器上进行身份验证。代理商服务器必需返回一个Proxy-Authenticate使用以进行身份讯问。用户端可以返回一个Proxy-Authorization信息头使用以验证。

• 408 Request Timeout
  请求超时。根据HTTP规范，用户端没有在服务器预备等待的时间内完成一个请求的发送，用户端可以随时再次提交这一请求而无需进行任何更改。

• 409 Conflict
  表示由于请求存在冲突无法解决该请求，例如多个同步升级之间的编辑冲突。

• 410 Gone
  表示所请求的资源不再可使用，将不再可使用。当资源被有意地删除并且资源应被清理时，应该用这个。在收到410状态码后，使用户应中止再次请求资源。但大多数服务端不会用此状态码，而是直接用404状态码。

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

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

• 413 Request Entity Too Large（RFC 7231）
  前称“Request Entity Too Large”，表示服务器拒绝解决当前请求，由于该请求提交的实体数据大小超过了服务器愿意或者者能够解决的范围。此种情况下，服务器可以关闭连接以免用户端继续发送此请求。
  假如这个状况是临时的，服务器应当返回一个Retry-After的响应头，以告知用户端可以在多少时间以后重新尝试。

• 414 Request-URI Too Long（RFC 7231）

前称“Request-URI Too Long”，表示请求的URI长度超过了服务器能够解释的长度，因而服务器拒绝对该请求提供服务。通常将太多数据的结果编码为GET请求的查询字符串，在这种情况下，应将其转换为POST请求。这比较少见，通常的情况包括：

本应用POST方法的表单提交变成了GET方法，导致查询字符串过长。

重定向URI“黑洞”，例如每次重定向把旧的URI作为新的URI的一部分，导致在若干次重定向后URI超长。
用户端正在尝试利使用某些服务器中存在的安全漏洞攻击服务器。这类服务器用固定长度的缓冲读取或者操作请求的URI，当GET后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行。没有此类漏洞的服务器，应当返回414状态码。

• 415 Unsupported Media Type
  对于当前请求的方法和所请求的资源，请求中提交的互联网媒体类型并不是服务器中所支持的格式，因而请求被拒绝。例如，用户端将图像上传格式为svg，但服务器要求图像用上传格式为jpg。

• 416 Requested Range Not Satisfiable（RFC 7233）
  前称“Requested Range Not Satisfiable”。用户端已经要求文件的一部分（Byte serving），但服务器不能提供该部分。例如，假如用户端要求文件的一部分超出文件尾端。

• 417 Expectation Failed
  在请求头Expect中指定的预期内容无法被服务器满足，或者者这个服务器是一个代理商服显的证据证实在当前路由的下一个节点上，Expect的内容无法被满足。

• 418 I’m a teapot（RFC 2324）
  本操作码是在1998年作为IETF的传统愚人节笑话, 在RFC 2324超文本咖啡壶控制协议’中定义的，并不需要在真实的HTTP服务器中定义。当一个控制茶壶的HTCPCP收到BREW或者POST指令要求其煮咖啡时应当回传此错误。这个HTTP状态码在某些网站（包括Google.com）与项目（如Node.js、ASP.NET和Go语言）中使用作彩蛋。

• 420 Enhance Your Caim
  Twitter Search与Trends API在用户端被限速的情况下返回。

• 421 Misdirected Request （RFC 7540）
  该请求针对的是无法产生响应的服务器（例如由于连接重使用）。

• 422 Unprocessable Entity（WebDAV；RFC 4918 ）
  请求格式正确，但是因为含有语义错误，无法响应。

• 423 Locked（WebDAV；RFC 4918）
  当前资源被锁定。

• 424 Failed Dependency（WebDAV；RFC 4918）
  因为之前的某个请求发生的错误，导致当前请求失败，例如PROPPATCH。

• 425 Unordered Collection
  在WebDAV Advanced Collections Protocol中定义，但Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol中并不存在。

• 426 Upgrade Required（RFC 2817）
  用户端应当切换到TLS/1.0，并在HTTP/1.1 Upgrade header中给出。

• 428 Precondition Required (RFC 6585)
  原服务器要求该请求满足肯定条件。这是为了防止“‘未升级’问题，即用户端读取（GET）一个资源的状态，更改它，并将它写（PUT）回服务器，但这期间第三方已经在服务器上更改了该资源的状态，因而导致了冲突。”

• 429 Too Many Requests （RFC 6585）
  使用户在给定的时间内发送了太多的请求。旨在使用于网络限速。

• 431 Request Header Fields Too Large （RFC 6585）
  服务器不愿解决请求，由于一个或者多个头字段过大。

• 444 No Response
  Nginx上HTTP服务器扩展。服务器不向用户端返回任何信息，并关闭连接（有助于阻止恶意软件）。

• 450 Blocked by Windows Parental Controls
  这是一个由Windows家庭控制（Microsoft）HTTP阻止的450状态代码的示例，使用于信息和测试。

• 451 Unavailable For Legal Reasons
  该访问因法律的要求而被拒绝，由IETF在2015核准后新添加加。

• 494 Request Header Too Large
  在错误代码431提出之前Nginx上用的扩展HTTP代码。

5xx服务器错误

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

• 500 Internal Server Error
  通使用错误消息，服务器遇到了一个未曾意料的状况，导致了它无法完成对请求的解决。没有给出具体错误信息。

• 501 Not Implemented
  服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。（例如，网络服务API的新功能）

• 502 Bad Gateway
  作为网关或者者代理商工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

• 503 Service Unavailable
  因为临时的服务器维护或者者过载，服务器当前无法解决请求。这个状况是暂时的，并且将在一段时间以后恢复。假如能够估计推迟时间，那么响应中可以包含一个Retry-After头使用以标明这个推迟时间。假如没有给出这个Retry-After信息，那么用户端应当以解决500响应的方式解决它。

• 504 Gateway Timeout
  作为网关或者者代理商工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者者辅助服务器（例如DNS）收到响应。
  注意：某些代理商服务器在DNS查询超时时会返回400或者者500错误。

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

• 506 Variant Also Negotiates（RFC 2295）
  由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误，被请求的协商变元资源被配置为在透明内容协商中用自己，因而在一个协商解决中不是一个合适的重点。

• 507 Insufficient Storage（WebDAV；RFC 4918）
  服务器无法存储完成请求所必需的内容。这个状况被认为是临时的。

• 508 Loop Detected （WebDAV；RFC 5842）
  服务器在解决请求时陷入死循环。 （可代替 208状态码）

• 510 Not Extended（RFC 2774）
  获取资源所需要的策略并没有被满足。

• 511 Network Authentication Required （RFC 6585）
  用户端需要进行身份验证才能取得网络访问权限，旨在限制使用户群访问特定网络。（例如连接WiFi热点时的强制网络门户）

参考资料
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
https://baike.so.com/doc/5328824-5563996.html
https://zh.wikipedia.org/wiki/HTTP状态码
[雪峰磁针石博客]python外部库详情-requests：人性化的HTTP