cookie

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。 它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了AJAX只能 同源 使用的限制。 本文详细介绍CORS的内部机制。 一、简介 CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。 整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。 因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。 二、两种请求 浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。 只要同时满足以下两大条件，就属于简单请求。 （1) 请求方法是以下三种方法之一： HEAD GET POST （2）HTTP的头信息不超出以下几种字段： Accept Accept-Language Content-Language Last-Event-ID Content-Type：只限于三个值 application/x-www-form

什么是Cookie？ Cookie是服务器在本地机器上存储的小段文本，它是一个简单的字符串形式的键值对。 网络服务器用HTTP头向客户端发送cookie， (一般情况下Cookie是由服务端生成的，当然js也能操作cookie) 在客户端，浏览器解析这些cookies并将它们保存到本地， 而后当浏览器访问这个服务器时，它会在任何请求上加上这些cookie。 说白了就是每次你和服务器的交互都会带着这些cookie。 什么是Session？ session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接。 然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义，“面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始

Asp.Net Core存储Cookie不成功 Asp.Net Core2.1生成的项目模板默认实现了 <> ，所以设置存储Cookie需要做一些处理。 1.第一种是在Startup的ConfigureServices方法中关闭这个支持. services.Configure<CookiePolicyOptions>(option => { option.CheckConsentNeeded = context => false; }); 2.设置存储的Cookie为重要 this.Response.Cookies.Append("stdio", DateTime.Now.ToString(), new CookieOptions { IsEssential = true }); 来源： https://www.cnblogs.com/zzr-stdio/p/10617532.html

5.1.13 JSP 中 include 指令和 include 动作有什么区别 include 的主要作用是用来在当前文件中引入另外一个文件，以便在当前文件中使用，例如，当应用程序中的所有页面的某些部分（例如标题、页脚、导航栏等）都一模一样时，就可以考虑把相同的部分提取出来写入一个单独的文件中，然后通过 include 方式引入。 include 有两种使用方法：include 指令和 include 动作。其中，include 指令的使用方法为：＜％＠include file＝＂test.jsp＂％＞，include 动作的使用方法为：＜jsp：include page＝＂test.jsp＂flush＝＂true＂＞＜jsp：param name＝＂name＂value＝＂value＂/＞＜/jsp：include＞。 include 指令与 include 动作之间的根本性差异在于二者被调用的时间。include 指令是编译阶段的指令，即在编译时，编译器会把指令所指向目标文件的内容复制到指令所在的位置，替换指令，最终形成一个文件，在运行时只有一个文件。也就是说，include 指令所包含文件的内容是在编译时插入到 JSP 文件中的，当文件内容有变化时就需要重写编译，因此适合于包含静态页面的情况，例如可以包含一个 Servlet。 而 include 动作是运行时的语法

1）用户没登陆用户名和密码,添加商品, 关闭浏览器再打开后 不登录 用户名和密码 　问：购物车商品还在吗？ 2）用户登陆了用户名密码,添加商品,关闭浏览器再打开后 不登录 用户名和密码 　问:购物车商品还在吗？ 3）用户登陆了用户名密码,添加商品, 关闭浏览器,然后再打开, 登陆用户名和密码 问:购物车商品还在吗？ 4）用户登陆了用户名密码,添加商品, 关闭浏览器 外地老家打开浏览器 登陆用户名和密码 问：购物车商品还在吗？ 上面四个问题都是以京东为模板, 那么大家猜猜结果是什么呢？ １）在 ２）不在了 ３）在 ４）在 如果你能够猜到答案, 那么说明你真的很棒, 那么关于这四点是怎么实现的呢?　（如果有不认可的小伙伴可以用京东实验一下） 下面我们就来讲解下购物车的原理,最后再来说下具体的code实现. 1)用户没有登录, 添加商品, 此时的商品是被添加到了浏览器的Cookie中, 所以当再次访问时(不登录),商品仍然在Cookie中, 所以购物车中的商品还是存在的. 2)用户登录了,添加商品, 此时会将Cookie中和用户选择的商品都添加到购物车中, 然后删除Cookie中的商品. 所以当用户再次访问(不登录),此时Cookie中的购物车商品已经被删除了, 所以此时购物车中的商品不在了. 3)用户登录, 添加商品,此时商品被添加到数据库做了持久化存储, 再次打开登录用户名和密码,

1. 对Django的认识？ #1.Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。 #2.Django内置的ORM跟框架内的其他模块耦合程度高。 # 应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利； # 理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。 #3.Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。 #4.Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。 #5.Django模板的设计哲学是彻底的将代码、样式分离； Django从根本上杜绝在模板中进行编码、处理数据的可能。 2. Django 、Flask、Tornado的对比 #1.Django走的是大而全的方向,开发效率高。它的MTV框架,自带的ORM,admin后台管理,自带的sqlite数据库和开发测试用的服务器 #给开发者提高了超高的开发效率 #2.Flask是轻量级的框架,自由,灵活,可扩展性很强,核心基于Werkzeug WSGI工具和jinja2模板引擎 #3

1、什么是会话 在日常生活中，从拨通电话到挂断电话之间的一连串的你问我答的过程就是一个会话。Web应用中的会话过程类似于生活中的打电话过程，它指的是一个客户端(浏览器)于web服务器之间连续发生的一系列请求和响应过程，例如，一个用户在某网络上的整个购物过程就是一个会话。 在打电话过程中，通话双方会有通话内容，同样，在客户端与服务器交互的过程中，也会产生一些数据。例如，用户甲和乙分别登陆了购物网站，甲购买了一个Nokia手机，乙购买了一个Ipad，当这两个用户结账时，web服务器需要对用户甲和乙的信息分别进行保存。在前面章节讲解的对象中，HttpServletRequest对象和ServletContext对象都可以对数据进行保存，但是这两个对象都不可行，具体原因如下： 1）客户端请求web服务器时，针对每次http请求，web服务器都会创建一个HttpServletRequest对象，该对象只能保存本次请求所传递的数据。由于购买和结账是两个不同的请求，因此，在发送结账请求时，之前购买请求中的数据将会丢失 2）使用ServletContext对象保存数据时，由于同一个Web应用共享的是同一个ServletContext对象，因此，当用户在发送结账请求时，由于无法区分哪些商品是哪个用户所购买的，而会将该购买网站中所有用户购买的商品进行结算，这显然也是不可行的 3

有时需要将网页中的一些数据保存在浏览器端，这样做的好处是，当下次访问页面时，不需要再次向服务器请求数据，直接就可以从本地读取数据。目前常用的有以下几种方法： cookie cookie会随着每次HTTP请求头信息一起发送，无形中增加了网络流量，另外，cookie能存储的数据容量有限，根据浏览器类型不同而不同，IE6大约只能存储2K。 Flash ShareObject 这种方式能能解决上面提到的cookie存储的两个弊端，而且能够跨浏览器，应该说是目前最好的本地存储方案。不过，需要在页面中插入一个Flash，当浏览器没有安装Flash控件时就不能用了。所幸的是，没有安装Flash的用户极少。 缺点：需要安装Flash插件。 Google Gear Google开发出的一种本地存储技术。 缺点：需要安装Gear组件。 userData IE浏览器可以使用userData来存储数据，容量可达到640K，这种方案是很可靠的，不需要安装额外的插件。缺点：它仅在IE下有效。 sessionStorage 使用于Firefox2+的火狐浏览器，用这种方式存储的数据仅窗口级别有效，同一个窗口（或者Tab）页面刷新或者跳转，都能获取到本地存储的数据，当新开窗口或者页面时，原来的数据就失效了。 缺点：IE不支持、不能实现数据的持久保存。 globalStorage 使用于Firefox2

基本概念 Cookie Cookie 是小甜饼的意思。顾名思义，cookie 确实非常小，它的大小限制为4KB左右。它的主要用途有保存登录信息，比如你登录某个网站市场可以看到“记住密码”，这通常就是通过在 Cookie 中存入一段辨别用户身份的数据来实现的。 localStorage localStorage 是 HTML5 标准中新加入的技术，它并不是什么划时代的新东西。早在 IE 6 时代，就有一个叫 userData 的东西用于本地存储，而当时考虑到浏览器兼容性，更通用的方案是使用 Flash。而如今，localStorage 被大多数浏览器所支持，如果你的网站需要支持 IE6+，那以 userData 作为你的 polyfill 的方案是种不错的选择。 sessionStorage sessionStorage 与 localStorage 的接口类似，但保存数据的生命周期与 localStorage 不同。做过后端开发的同学应该知道 Session 这个词的意思，直译过来是“会话”。而 sessionStorage 是一个前端的概念，它只是可以将一部分数据在当前会话中保存下来，刷新页面数据依旧存在。但当页面关闭后，sessionStorage 中的数据就会被清空。 三者的异同 特性 Cookie localStorage sessionStorage 数据的生命期

一、什么是localStorage、sessionStorage 在HTML5中，新加入了一个localStorage特性，这个特性主要是用来作为本地存储来使用的，解决了cookie存储空间不足的问题(cookie中每条cookie的存储空间为4k)，localStorage中一般浏览器支持的是5M大小，这个在不同的浏览器中localStorage会有所不同。 二、localStorage的优势与局限 localStorage的优势 1、localStorage拓展了cookie的4K限制 2、localStorage会可以将第一次请求的数据直接存储到本地，这个相当于一个5M大小的针对于前端页面的数据库，相比于cookie可以节约带宽，但是这个却是只有在高版本的浏览器中才支持的 localStorage的局限 1、浏览器的大小不统一，并且在IE8以上的IE版本才支持localStorage这个属性 2、目前所有的浏览器中都会把localStorage的值类型限定为string类型，这个在对我们日常比较常见的JSON对象类型需要一些转换 3、localStorage在浏览器的隐私模式下面是不可读取的 4、localStorage本质上是对字符串的读取，如果存储内容多的话会消耗内存空间，会导致页面变卡 5、localStorage不能被爬虫抓取到