http请求

一.HTTP简介 1.HTTP协议，即 超文本传输协议 (Hypertext transfer protocol)。是一种详细规定了 浏览器和万维网(WWW = World Wide Web)服务器 之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。 2.HTTP协议作为TCP/IP模型中应用层的协议也不例外。HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。如下图： 3.HTTP是一个 应用层协议 ，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个 无状态 的协议。 4.HTTP默认的端口号为 80 ，HTTPS的端口号为 443 。 5.浏览网页是HTTP的主要应用，但是这并不代表HTTP就只能应用于网页的浏览。HTTP是一种协议，只要通信的双方都遵守这个协议，HTTP就能有用武之地。比如咱们常用的QQ，迅雷这些软件，都会使用HTTP协议(还包括其他的协议)。 二.HTTP特点 1、 简单快速 ：客户向服务器请求服务时，只需传送 请求方法 和 路径 。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 2、 灵活 ：HTTP允许 传输任意类型的数据对象 。正在传输的类型由Content-Type加以标记。 3、 HTTP 0.9和1.0使用非持续连接

为了防止CSRF的攻击，我们建议修改浏览器在发送POST请求的时候加上一个Origin字段，这个Origin字段主要是用来标识出最初请求是从哪里发起的。如果浏览器不能确定源在哪里，那么在发送的请求里面Origin字段的值就为空。 隐私方面：这种Origin字段的方式比Referer更人性化，因为它尊重了用户的隐私。 1、Origin字段里只包含是谁发起的请求，并没有其他信息 (通常情况下是方案，主机和活动文档URL的端口)。跟Referer不一样的是，Origin字段并没有包含涉及到用户隐私的URL路径和请求内容，这个尤其重要。 2、Origin字段只存在于POST请求，而Referer则存在于所有类型的请求。 随便点击一个超链接（比如从搜索列表里或者企业intranet），并不会发送Origin字段，这样可以防止敏感信息的以外泄露。 在应对隐私问题方面，Origin字段的方法可能更能迎合用户的口味。 服务端要做的：用Origin字段的方法来防御CSRF攻击的时候，网站需要做到以下几点： 1、在所有能改变状态的请求里，包括登陆请求，都必须使用POST方法。对于一些特定的能改变状态的GET请求必须要拒绝，这是为了对抗上文中提到过的论坛张贴的那种危害类型。 2、对于那些有Origin字段但是值并不是我们希望的（包括值为空）请求，服务器要一律拒绝。比如

从web客户端（浏览器）来说： 最直接的区别，GET请求的参数是放在URL里的，POST请求参数是放在请求body里的； GET请求的URL传参有长度限制，而POST请求没有长度限制； GET请求的参数只能是 ASCII码，所以中文需要 URL编码，而 POST请求传参没有这个限制； HTTP 请求来说： 其实， GET和 POST本质上两者没有任何区别。他们都是 HTTP协议中的请求方法。底层实现都是基于 TCP/IP协议。上述的所谓区别，只是浏览器厂家根据约定，做得限制而已。 HTTP请求最初设定了八种方法，这八种方法本质上没有任何区别。只是让请求，更加有语义： OPTIONS 返回服务器所支持的请求方法 GET 向服务器获取指定资源 HEAD 与GET一致，只不过响应体不返回，只返回响应头 POST 向服务器提交数据，数据放在请求体里 PUT 与POST相似，只是具有幂等特性，一般用于更新 DELETE 删除服务器指定资源 TRACE 回显服务器端收到的请求，测试时候会用到这个 CONNECT 预留，暂无使用 关于RESTful API 服务端根据不同的请求方式，可以做不同的处理，同时，根据不同的请求，还可以设计出不同风格的应用程序接口，这就引出了Representational State Transfer，英文缩写就是REST，中文意思是表述性状态转移（和没翻译差不多）

http的请求方法 1.GET--获取资源 2.HEAD--获取资源的元信息 3.POST--提交数据 4.PUT--修改数据 5.DELETE--删除资源 6.CONNECT--建立链接隧道，用于代理服务器 7.OPTIONS--列出可对资源实行的请求方法，用来跨域请求 8.TRACE--追踪请求-响应的传输路径 GET和POST的区别 缓存角度：get请求会被浏览器主动缓存下来，留下历史记录，而post默认不会。 编码角度：get 只能进行 URL 编码，只能接收 ASCII 字符，而 post 没有限制。 参数角度：get 一般放在 URL 中，因此不安全，post 放在请求体中，更适合传输敏感信息。 TCP角度：get 请求会把请求报文一次性发出去，而 post 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。 http 状态码 1xx: 表示目前是协议处理的中间状态，还需要后续操作。 2xx: 表示成功状态。 3xx: 重定向状态，资源位置发生变动，需要重新请求。 4xx: 请求报文有误。 5xx: 服务器端发生错误。 来源： https://www.cnblogs.com/susu2020/p/12552848.html

所有 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 代理认证请求 — 客户机首先必须使用代理认证自身。 415 介质类型不受支持 — 服务器拒绝服务请求，因为不支持请求实体的格式。 5xx 服务器中出现的错误 500 内部错误 — 因为意外情况，服务器不能完成请求。 501 未执行

HTTP请求415错误 – 不支持的媒体类型(Unsupported media type) 通常有以下情况： 1：检查你的 http 请求头信息，比如 因为 User-Agent 被服务器设置 拒绝请求了； 比如你写的的爬虫，就很有可能因为没有伪装成浏览器，被拒绝请求 user-agent 详情 2：查看你的 http 请求方法，以及服务器端的设置 比如：有一个 强制用 post 请求的接口，你是不是用了非post 请求 3：post 请求参数设置，是不是必须的，json 格式 比如下面，两段代码， 如下 json参数，body import requests import json payload={"userName":"names","userCode":"123456","phoneNum":"7800","regPic":"picData"} headers={'content-type': 'application/json'} burl="http://httpbin.org/post" r=requests.post(burl, data=json.dumps(payload), headers=headers) print r.text 如下 form 格式 参数 import requests import json payload={"userName":

转载：http://blog.csdn.net/xu_zh_h/article/details/2294233 4 请求失败4xx 4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同一个请求。（例如，增加合适的认证信息）。不过，同一个请求交给不同服务器也许就会成功。 4.1 400 Bad Request 请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误，比如”Missing Call-ID header field”。 4.2 401 Unauthorized 请求需要用户认证。这个应答是由UAS和注册服务器产生的，当407（Proxy Authentication Required）是proxy服务器产生的。 4.3 402 Payment Required 保留/以后使用 4.4 403 Forbidden 服务端支持这个请求，但是拒绝执行请求。增加验证信息是没有必要的，并且请求应当不被重试。 4.5 404 Not Found 服务器返回最终信息：用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下， 也会产生这个应答。 4.6 405 Method Not Allowed 服务器支持Request-Line中的方法

4 请求失败4xx 4xx应答定义了特定服务器响应的请求失败的情况。客户端不应当在不更改请求的情况下重新尝试同一个请求。（例如，增加合适的认证信息）。不过，同一个请求交给不同服务器也许就会成功。 4.1 400 Bad Request 请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误，比如”Missing Call-ID header field”。 4.2 401 Unauthorized 请求需要用户认证。这个应答是由UAS和注册服务器产生的，当407（Proxy Authentication Required）是proxy服务器产生的。 4.3 402 Payment Required 保留/以后使用 4.4 403 Forbidden 服务端支持这个请求，但是拒绝执行请求。增加验证信息是没有必要的，并且请求应当不被重试。 4.5 404 Not Found 服务器返回最终信息：用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下， 也会产生这个应答。 4.6 405 Method Not Allowed 服务器支持Request-Line中的方法，但是对于这个Request-URI中的地址来说，是不允许应用这个方法的。 应答必须包括一个Allow头域

最常用的Http请求无非是get和post，get请求可以获取静态页面，也可以把参数放在URL字串后面，传递给servlet，post与get的不同之处在于post的参数不是放在URL字串里面，而是放在http请求的正文内。 在Java中可以使用HttpURLConnection发起这两种请求，了解此类，对于了解soap，和编写servlet的自动测试代码都有很大的帮助。 下面的代码简单描述了如何使用HttpURLConnection发起这两种请求，以及传递参数的方法： public class HttpInvoker { public static final String GET_URL = "http://localhost:8080/welcome1"; public static final String POST_URL = "http://localhost:8080/welcome1"; public static void readContentFromGet() throws IOException { // 拼凑get请求的URL字串，使用URLEncoder.encode对特殊和不可见字符进行编码 String getURL = GET_URL + "?username=" + URLEncoder.encode("fat man", "utf-8");

AJAX中请求远端文件、或在检测远端文件是否掉链时，都需要了解到远端服务器反馈的状态以确定文件的存在 与否。 当然，在我们平常浏览网页时，也会发现一些文件不存在时显示为“404错误”，这就是常见的Http请求状态（status） 　　Web服务器响应浏览器或其他 客户 程序的请求时，其应答一般由以下几个部分组成：一个状态行，几个应答头，一个空行，内容文档。下面是一个最 简单 的应答： 　 　状态行包含HTTP版本、状态代码、与状态代码对应的简短说明信息。在大多数情况下，除了Content-Type之外的所有应答头都是可选的。但 Content-Type是必需的，它描述的是后面文档的MIME类型。虽然大多数应答都包含一个文档，但也有一些不包含，例如对HEAD请求的应答永远 不会附带文档。有许多状态代码实际上用来标识一次失败的请求，这些应答也不包含文档（或只包含一个简短的错误信息说明）。 　　当用户试图通过 HTTP 访问一台正在运行 Internet 信息服务 (IIS) 的服务器上的内容时，IIS 返回一个表示该请求的状态的数字代码。状态代码可以指明具体请求是否已成功，还可以揭示请求失败的确切原因。 1xx - 信息提示 这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 ·0 - 本地响应成功。 　· 100 - Continue