这个问题首先你要明白，WKWebView有自己的进程，使用自己的存储空间来存储cookie和cache，WKWebView会忽视NSURLCache、NSHTTPCookieStorage、NSCredentialStorage这些默认的网络存储， 其他的网络类如NSURLConnection是无法访问到的。 同时WKWebView发起的资源请求也是不经过NSURLProtocol的，导致无法自定义请求。
起因：http是无状态的，因此我们通常需要用到cookie以及session来保存状态，session是在服务器端存储的，会和cookie一起使用，设置了session之后，会发送给浏览器一个cookie,这个cookie是session_id，当再次请求的时候浏览器会将它发送给服务器，以此来找到对应的session. 但是，我们实际使用的时候通常会用到跨域，就是向不同的域发起请求，但是默认情况下此时cookie是不会发送给服务器的，此时就导致了丢失session_id,从而导致了session的值为undefined。解决方案如下： 首先，前端页面发起ajax请求时，加上参数：
在web开发中，我们经常后听到前端程序员的依据抱怨"又重启了啊？我又要重新登录"，这是因为在传统的web开发中，服务器一旦关机，内存中的会话信息会丢失，就跟前端开发存在变量中的数据，浏览器刷新后会丢失一样。为了解决这个问题，引入了session持久化的概念，将服务端和客户端的会话信息保存到一个载体中，不管服务器怎么重启，只要载体中的信息没有丢失，就能拿到会话信息，载体一般为数据库或者文件，但是，得益于redis的特性，我们一般选择用redis作为存储载体。下面是nodejs中用redis做session持久化的例子
导语 WKWebView 是苹果在 WWDC 2014 上推出的新一代 webView 组件，用以替代 UIKit 中笨重难用、内存泄漏的 UIWebView。WKWebView 拥有60fps滚动刷新率、和 safari 相同的 JavaScript 引擎等优势。 简单的适配方法本文不再赘述，主要来说说适配 WKWebView 过程中填过的坑以及善待解决的技术难题。 1、WKWebView 白屏问题 WKWebView 自诩拥有更快的加载速度，更低的内存占用，但实际上 WKWebView 是一个多进程组件
1、Cookie和session的认识 Cookie(曲奇)：用户识别。 西游记： 李世民 通关文牒 唐僧 通关文牒 女儿国 通关文牒 比丘国 http请求实际是无状态 用户向服务器发起请求，服务器下发cookie到本地，下次请求，用户携带cookie进行请求， Cookie解决用户身份问题 但是cookie不安全
近来用户反映希望我们把在线编辑器中的多图片上传功能实现，因为他们在编辑商品描述时经常会有一次上传多张图片的需求，如果要逐张选择的话效率很低，客户的需求就是我们的追求，很快我们就把完善功能排到了日程表中，要求尽快实现。
Android页面嵌套了一个h5，H5页面内部有用户登陆页面，发现h5页面的登陆功能无法使用，一直登陆失败。和web那边商量一会，发现js写入的cookie丢失了。所有需要Android这边在重写写入一次。
typeof与instanceof都是判断数据类型的方法，区别如下： typeof会返回一个变量的基本类型，instanceof返回的是一个布尔值。instanceof 可以准确地判断复杂引用数据类型，但是不能正确判断基础数据类型。而 typeof 也存在弊端，它虽然可以判断基础数据类型（null 除外），但是引用数据类型中，除了 function 类型以外，其他的也无法判断。可以看到，上述两种方法都有弊端，并不能满足所有场景的需求 如果需要通用检测数据类型，可以采用Object.prototype.toString，调用该方法，统一返回格式“[object Xxx]” 的字符串。
微信内网页不可使用 local/sessionStorage 储存，因为它只是一个 webview 组件，并不是一个浏览器。 但是我们可以使用 cookie 储存的方式
回顾 在web后台开发中我们经常需要存储一些变量到session中进行暂存，最为特殊的就是“购物车”，由于http的无状态特性，因此我们需要在客户端打上一个标记，唯一的标示客户端并和服务端session一一对应，因此就有了通过cookie和url进行存储或传递这个标示－－sessionID。 sessionID是一个长的字符串，它往往默认通过cookie来保存，这个session并不持久化到硬盘而是暂存到内存中，每次请求时都会在head中带上这个包含sessionID的cookie，服务端可以根据该id标
html5有哪些新特性、移除了那些元素？如何处理HTML5新标签的浏览器兼容问题？如何区分 HTML 和 HTML5？
UIWebView是苹果继承于UIView封装的一个加载web内容的类,它可以加载任何远端的web数据展示在你的页面上，你可以像浏览器一样前进后退刷新等操作。不过苹果在iOS8以后推出了WKWebView来加载Web。UIWebView自iOS2就有，WKWebView从iOS8才有，毫无疑问WKWebView是将会逐步取代笨重的UIWebView。且UIWebView存在占用过多内存，js执行效率低等问题。而WKWebView网页加载速度大有提升，占用更少内存。
在登录页面登录成功后后台返回一个 token（该 token 用于验证用户登录状态），将 token 保存在 cookies 和 store 里。之后每次在向后端发送请求时在 header 里添加一个 token 字段用于验证用户状态，如果 token 失效，接口返回状态码 300, 使用 axios 创建一个拦截器，如果返回接口的状态码为300，将清除cookies 和 store 里的 token 值并转到登录页面。
今日菜谱——红烧嗨鸟！ 前面有很多读者希望我能讲一讲关于Hybrid的东西，我想劝你们早日放弃，但毕竟有很多朋友都是不到黄河心不死，也有很多朋友是因为打不过PM才被妥协。但不管怎么样，看来我也是得
HTML 1、Doctype作用？标准模式与兼容模式各有什么区别? （1）、<!DOCTYPE>声明位于位于HTML文档中的第一行，处于<html> 标签之前。告知浏览器的解析器用什么文档标准解析这
cookie + session 是为了保存用户状态信息的。比如这个用户是否已经登陆，如果登陆了就给这个用户推送一些信息，比如他最近买一些东西、他的购物车、他最近看过的文章或视频等信息。因为 http 是无状态的，所谓的无状态就是说每次请求完成后，不会在客户端和服务器上保存任何的信息。对于客户端和服务器而言，根本就不知道上次请求的信息是什么，甚至不知道本次连接的对端是不是上次连接的那一端。也就是说即使该用户登录了，但 HTTP 本身并不知道是哪个用户登陆了，HTTP 只处理请求与相应。因此如何知道一个用户登录了之后，后端能知道是哪个用户登录了，这是一个问题。
原因：刷新页面时，vue实例重新加载，从而，store也被重置了。store是用来存储组件状态的，而不是用来做本地数据存储的。所以，对于不希望页面刷新之后被重置的数据，使用本地存储来进行存储。
输入url后，首先需要找到这个url域名的服务器ip,为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：浏览器缓存-》系统缓存-》路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器。
本文章产生的缘由是因为专业老师，让我给本专业的同学讲一哈SQL注入和XSS入门,为了备课，于是产生了这篇文章。
大家好，我是柒八九。我们在网络拾遗之Http缓存文章中，从网络协议的视角介绍了网站「客户端缓存」 中的HTTP缓存策略，并对「强缓存」和「协商缓存」做了较为详细的介绍。
网站通常会使用 cookie来记录用户的登录状态，但并非安全，因为 cookie被允许在第三方网站（也不仅限于第三方）发起的请求中携带，因此利用这一点可以达到 CSRF 攻击。本文不再对 CSRF 的原理作过多阐述，点击这里了解CSRF 。 如果别人问起防 CSRF 的方法有哪些，大家通常会说出：Token + Referer，该方案在业界已经非常成熟。当一个问题有了解决办法后，就很人有人会去了解别的方案，我想听听不同的声音。
ookie数据大小不能超过4ksessionStorage和localStorage虽然也有存储大小的限制，但比cookie大得多，可以达到5M或更大
UIWebView 是苹果继承于 UIView 封装的一个加载 web 内容的类,它可以加载任何远端的web数据展示在你的页面上，你可以像浏览器一样前进后退刷新等操作。不过苹果在 iOS8 以后推出了 WKWebView 来加载 Web，并应用于 iOS 和 OSX 中，它取代了 UIWebView 和 WebView ，在两个平台上支持同一套 API。
---- 相关知识点 web标准、 web语义化、 浏览器内核、 兼容性、 html5... 题目&答案 Doctype作用？严格模式与混杂模式如何区分？它们有何意义（1）<!DOCTYPE>声明位于HTML文档中的第一行，处于<html>标签之前，用于告知浏览器的解析器用什么文档标准解析这个文档。DOCTYPE不存在或格式不正确会导致文档以兼容模式呈现。 （2）标准模式的排版和JS运作模式都是以该浏览器支持的最高标准运行。在兼容模式中，页面以宽松的向后兼容的方式显示，模拟老式浏览器的行为以防止站点
反爬虫常见套路 判断user-agent 校验referer头 校验cookie 同一IP访问次数限制 js/ajax动态渲染页面 反反爬虫应对策略 1、user-age
一、使用良好的结构 可扩展 HTML (XHTML) 具有许多优势，但是其缺点也很明显。XHTML 可能使您的页面更加符合标准，但是它大量使用标记（强制性的 和 标记），这意味着浏览器要下载更多代码。所以，事情都有两面性，尝试在您的网页中使用较少的 XHTML 代码，以减小页面大小。如果您确实不得不使用 XHTML，试着尽可能对它进行优化。
前言 我们大前端团队内部 📖每周一练 的知识复习计划继续加油，本篇文章是 《Hybrid APP 混合应用专题》 主题的第二期和第三期的合集。 这一期共整理了 10 个问题，和相应的参考答案，文字和图片较多，建议大家可以收藏，根据文章目录来阅读。 之前分享的每周内容，我都整理到掘金收藏集 📔《EFT每周一练》 上啦，欢迎点赞收藏咯💕💕。 内容回顾： 《EFT 每周分享 —— Hybrid App 应用开发中 5 个必备知识点复习》 《EFT 每周分享 —— HTTP 的15个常
前言 我们大前端团队内部 ?每周一练 的知识复习计划继续加油，本篇文章是 《Hybrid APP 混合应用专题》 主题的第二期和第三期的合集。 这一期共整理了 10 个问题，和相应的参考答案，文字和图
let是局部变量（在他所在的代码块可用），const是常量，var是全局变量（前两个是ES6的，因为前面两个更加严谨，var被抛弃（貌似））
最近线上环境遇到一个问题，就是ASP.NET Core Web应用在单个容器使用正常，扩展多个容器无法访问的问题。查看容器日志，发现以下异常：
首先是订单表的设计，主要包括订单表和订单详情表，订单表主要包含订单的主要信息，比如订单的编号、总额、数量、状态、收货人信息等。其中收货人信息必须要冗余到订单表中，不能简单用Id进行管理。
Cross-site request forgery（跨站请求伪造）：在b.com发起a.com的请求，会自动带上a.com的cookie，如果cookie中有敏感的票据，会有攻击者伪造用户发送请求的安全问题
前言 我们大前端团队内部 ?每周一练 的知识复习计划继续加油，本篇文章是 《Hybrid APP 混合应用专题》 主题的第二期和第三期的合集。 这一期共整理了 10 个问题，和相应的参考答案，文字和
详细资料可以参考：《浅谈模块化开发》《Javascript 模块化编程（一）：模块的写法》《前端模块化：CommonJS，AMD，CMD，ES6》《Module 的语法》
申明：本文是学习2014版ASP.Net视频教程的学习笔记，仅供本人复习之用，也没有发布到博客园首页。
CSRF，是跨站请求伪造（Cross Site Request Forgery）的缩写，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
HTML5为我们提供了更多的语义化标签、更丰富的元素属性，以及更让人欣喜的功能。但在面试中，HTML5部分的面试题主要考察应试者对HTML5API的掌握情况，这是HTML5的重点，也正是这些API推动了前端的发展。
本地同一浏览器访问本地HTML文件和访问服务器端HTML文件，本地Iframe没有自适应高度，而服务器端的Ifrane自适应了高度。
XSS：跨站脚本攻击，Cross-Site Scripting，为了和前端的css避免重名，简称为XSS，是指通过技术手段，向正常用户请求的HTML页面中插入恶意脚本，执行。
在做网站的时候，都会用到用户登录的功能。对于一些敏感的资源，我们只希望被授权的用户才能够访问，这让然需要用户的身份验证。对于初学者，通常将用户登录信息存放在Session中，笔者在刚接触到asp.net的时候就是这么做的。当我将用户信息存在在Session中时，常常会遇到Session丢失导致用户无法正常访问被授权的资源，保持用户登录状态时的安全性问题，无休止的将用户导航到登录页面等莫名其妙的问题。
a. 请求数量：合并脚本和样式表，CSS Sprites，拆分初始化负载，划分主域
通过以上三种方式， 我想你应该能解决绝大多数父子组件通信的场景了，但让我们再仔细考虑一下上面的通信场景，就会发现它们还可能存在的问题： 从子组件向父组件传递数据时，父子组件中的数据仍不是每时每刻都同步的,
Object.prototype.isPrototypeOf 使用Object的原型方法isPrototypeOf，判断两个对象的原型是否一样, isPrototypeOf() 方法用于测试一个对象是否存在于另一个对象的原型链上。
HTML5中 Web Storage 的出现，主要是为了弥补使用 Cookie 作为本地存储的不足。Cookie 存储的数据量非常小，而且数据会自动携带到请求头里，但服务器端可能并不关心这些数据，所以会造成带宽的浪费。
微信小程序没有像浏览器一样内置实现了 cookie 方案，需要开发者自行模拟，而原先京东购物小程序及京喜小程序（现微信一级购物入口）是从微信及手 Q 购物入口 H5 中迁移迭代出来的，也就是说我们不仅要在小程序中模拟一套 cookie 方案，并且要保持和原业务对 cookie 处理逻辑的一致，为此我们将实现方向确定为“基于小程序开放能力，和浏览器保持一致”。
1.响应时间。 2.并发数。如果暂时没有对应的准确监控，针对不同业务模型，可以有不一样的并发数的预估。我们的系统进行峰值并发数预估的话，有一种比较粗略的计算方式，即全天请求平均每秒并发数 * 3。但也需要case by case。 3.吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）以及TPS（每秒处理事务数）。 4.性能计数器。包括系统负载、线程数、cpu、内存使用情况等。可以用top、free、cat /proc/cpuinfo等命令来查看。系统负载的定义为当前被CPU执行的线程数/等待被CPU执行的总线程数。当其值与逻辑cpu个数相同时是最佳状态，其代表所有的资源都被最大限度地被利用。但也有人认为当负载为0.7倍逻辑CPU数时最佳。 1)系统负载、任务、cpu、内存使用情况：
（1）合理的 title、description 和 keywords，他们的搜索权重逐个减小 title 强调重点即可，重要关键词出现不要超过2次，而且要靠前，不同页面 title 要有所不同；description 把页面内容高度概括，长度合适，不可过分堆砌关键词，不同页面 description 有所不同；keywords 列举出重要关键词即可。
为什么不用 iframe，这几乎是所有微前端方案第一个会被 challenge 的问题。但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 "炫技" 或者刻意追求 "特立独行"。
http: 超文本传输协议，是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
