Loading... # HTTP协议 ## HTTP请求类型 1. OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送 ’*' 的请求来测试服务器的功能性。 2. HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。 3. GET：向特定的资源发出请求。 4. POST：向指定资源提交数据进行处理（例如表单提交或者上传文件）。数据被包含在请求体中。POST请求可能会导致新资源的创建或已有资源的修改。 5. PUT：向指定资源上传其最新内容。 6. DELETE：请求服务器删除Request-URI 所标识的资源。 7. TRACE：回显服务器收到的请求，主要用于测试或诊断。 8. CONNECT：HTTP/1.1 协议中预留给能够连接改为管道方式的代理服务器。 ## HTTP报文结构 1. 客户端请求消息 - 请求行 （request line） - 请求头 （header） - 空行 - 请求数据  2. 服务器响应消息 - 状态行 - 消息报头 - 空行 - 响应正文  3. 实例 - 客户端请求 ``` GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Host: www.example.com Accept-Language: en, mi ``` - 服务端响应 ``` HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain ``` ## HTTP常见Header |应答头|说明| | :--------------- | ------------------------------------------------------------ | | Allow | 服务器支持哪些方法（如GET、POST等） | | Content-Encoding | 文档的编码（Encode）方法。只有在解码之后才可以看到 Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。 | | Content-Length | 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。 | | Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。 | | Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 | | Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ | | Last-Modified | 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 | | Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 | | Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。 注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。<br/><br/>注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV="Refresh" ...＞。<br/>注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。 | | Server | 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。 | |Set-Cookie|设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。| |WWW-Authenticate|客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。<br/>注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。| ## HTTP状态码 1. 常见HTTP状态码 - 200 - 请求成功 - 301 - 资源（网页）被永久重定向到其他URL - 404 - 请求的资源不存在 - 500 - 服务器内部错误 2. 服务器状态码分类 HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型： | 分类 | 分类描述 | | ---- | ---------------------------------------------- | | 1** | 信息，服务器收到请求，需要请求者继续执行操作 | | 2** | 成功，操作被成功接收并处理 | | 3** | 重定向，需要进一步的操作以完成请求 | | 4** | 客户端错误，请求包含语法错误或无法完成请求 | | 5** | 服务器错误，服务器在处理请求的过程中发生了错误 | 3.状态码列表 | 状态码 | 状态码英文名称 | 中文描述 | | ------ | ------------------------------- | ------------------------------------------------------------ | | 100 | Continue | 继续。[客户端](http://www.dreamdu.com/webbuild/client_vs_server/)应继续其请求 | | 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 | | 200 | OK | 请求成功。一般用于GET与POST请求 | | 201 | Created | 已创建。成功请求并创建了新的资源 | | 202 | Accepted | 已接受。已经接受请求，但未处理完成 | | 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 | | 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 | | 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 | | 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 | | 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 | | 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 | | 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI | | 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 | | 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 | | 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 | | 306 | Unused | 已经被废弃的HTTP状态码 | | 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 | | 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 | | 401 | Unauthorized | 请求要求用户的身份认证 | | 402 | Payment Required | 保留，将来使用 | | 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 | | 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 | | 405 | Method Not Allowed | 客户端请求中的方法被禁止 | | 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 | | 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 | | 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 | | 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 | | 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 | | 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 | | 412 | Precondition Failed | 客户端请求信息的先决条件错误 | | 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 | | 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 | | 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 | | 416 | Requested range not satisfiable | 客户端请求的范围无效 | | 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 | | 500 | Internal Server Error | 服务器内部错误，无法完成请求 | | 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 | | 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 | | 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 | | 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 | | 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 | ## Cookie常用字段 1. name：cookie 的名称 2. value：为一个cookie 的值 3. expires/Max-Age： 为此cookie超时时间。若设置其值为一个时间，那么当**到达**此时间后，此cookie失效。**不设置的话默认值是Session，意思是cookie会和session一起失效**。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。 4. domain： 1、域，指定关联的WEB服务器或域。 2、值是域名。这是对path路径属性的一个延伸。如果我们想让**dev.mycompany.com** 能够访问**bbs.mycompany.com**设置的cookies，该怎么办? 我们可以把domain属性设置成“mycompany.com”，并把path属性设置成“/”。不能把cookies**域属性**设置成与**设置它的服务器的所在域**不同的值。 **以下为domain的详细设置规则：** domain字段为可以访问此cookie的域名。 非顶级域名，如二级域名或者三级域名，设置的cookie的domain只能为顶级域名或者二级域名或者三级域名本身，不能设置其他二级域名的cookie，否则cookie无法生成。 顶级域名只能设置domain为顶级域名，不能设置为二级域名或者三级域名，否则cookie无法生成。 二级域名能读取设置了domain为顶级域名或者自身的cookie，不能读取其他二级域名domain的cookie。所以要想cookie在多个二级域名中共享，需要设置domain为顶级域名，这样就可以在所有二级域名里面或者到这个cookie的值了。 顶级域名只能获取到domain设置为顶级域名的cookie，其他domain设置为二级域名的无法获取。 5. http： cookie的httponly属性。若此属性为true，则只有在http请求头中会带有此cookie的信息，而不能通过document.cookie来访问此cookie。 1、如果在Cookie中设置了”HttpOnly”属性，那么通过后台程序读取，JS脚本将无法读取到Cookie信息，这样能有效的防止**XSS攻击**。 2、但是设置HttpOnly属性，**Cookie盗窃**的威胁并没有彻底消除，因为cookie还是有可能**传递的过程中**被**监听捕获**后信息泄漏。 6. path： path字段为可以访问此cookie的页面路径。 比如domain是abc.com,path是/test，那么只有/test路径下的页面可以读取此cookie。 1、路径，指定与cookie关联的WEB页。 2、值可以是一个目录，或者是一个路径。如果/head/index.html 建立了一个cookie，那么在/head/目录里的所有页面，以及该目录下面任何子目录里的页面都可以访问这个cookie。这就是说，在/head/stories/articles 里的任何页面都可以访问/head/index.html建立的cookie。但是，如果/zdnn/ 需要访问/head/index.html设置的cookies，该怎么办?这时，我们要把cookies的path属性设置成“/”。在指定路径的时候，凡是来自同一服务器，**URL里有相同路径的所有WEB页面都可以共享cookies**。现在看另一个例子：如果想让 /head/filters/ 和/head/stories/共享cookies，就要把path设成“/head”。 7. Secure： 设置是否只能通过https来传递此条cookie 1、安全，指定cookie的值通过网络如何在用户和WEB服务器之间传递。 2、这个属性的值或者是“secure”，或者为空。缺省情况下，该属性为空，也就是使用不安全的HTTP连接传递数据。如果一个 cookie 标记为secure，那么，它与WEB服务器之间就通过HTTPS或者其它安全协议传递数据。不过，设置了secure属性不代表其他人不能看到你机器本地保存的cookie。换句话说，把cookie设置为secure，只保证cookie与WEB服务器之间的数据传输过程加密，而保存在本地的cookie文件并不加密。如果想让本地cookie也加密，得自己加密数据。 ## cookie、session区别 - cookie 存储于浏览器端，而 session 存储于服务端 - cookie 的安全性相比于 session 较弱，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session。 - session 会在一定时间内保存在服务器上。当访问增多时，会占用服务器的资源，所以考虑到服务器性能方面，可以使用cookie - cookie 存储容量有限制，单个cookie 保存数据不能超过4k，且很多浏览器限制一个站点最多保存20个cookie。而对于 session ，其默认大小一般是1024k ## cookie、sessionStorage、localStorage 异同点 **html5 中 webStorage 包含 sessionStorage 和 localStorage** 共同点： - 都保存在浏览器端，且是同源的 区别： - cookie 数据始终在同源的http请求中携带，而 webStorage 不会再请求中携带，仅仅在本地存储 - 存储大小区别，cookie 是4k，webStorage 可以达到5M甚至更大 - 数据有效时间区别： sessionStorage 仅仅是会话级别的存储，它只在当前浏览器关闭前有效，不能持久保持；localStorage 始终有效，即使窗口或浏览器关闭也一直有效，除非用户手动删除，其才会失效；cookie 只在设置的 cookie 过期时间之前一直有效。 - 作用域区别：sessionStorage **不在不同的浏览器窗口中共享**，即使是同一个页面； localStorage 和 cookie 在所有同源窗口是共享的 - Web Storage 支持事件通知机制，可以将数据更新的通知发送给监听者。Web Storage 的 api 接口使用更方便。 ## web storage和cookie的区别 Web Storage的概念和cookie相似，区别是它是为了更大容量存储设计的。Cookie的大小是受限的，并且每次你请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可以跨域调用。 除此之外，Web Storage拥有setItem,getItem,removeItem,clear等方法，不像cookie需要前端开发者自己封装setCookie，getCookie。 但是Cookie也是不可以或缺的：Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在 ，而Web Storage仅仅是为了在本地“存储”数据而生。 Cookies:服务器和客户端都可以访问；大小只有4KB左右；有有效期，过期后将会删除； 本地存储：只有本地浏览器端可访问数据，服务器不能访问本地存储直到故意通过POST或者GET的通道发送到服务器；每个域5MB；没有过期数据，它将保留知道用户从浏览器清除或者使用Javascript代码移除 > 以上内容均参考于互联网 Last modification：November 21st, 2020 at 05:57 pm © 允许规范转载 Support If you think my article is useful to you, please feel free to appreciate ×Close Appreciate the author Sweeping payments
Comment here is closed