自从换了公司,这几年一直忙着招人。面试的时候,时不时挖个坑,看看别人会不会跳进去。。。好久没写文章了,顺便总结一下经验吧。。。我也不清楚如果我能写完,我能写多少。当然文章仅代表个人观点,觉得不对也没关系。1.GET和POST请求有什么区别?这是一个普遍的问题。有些文章说POST比GET安全,说实话,确实是扯淡。GET有长度限制,也是受浏览器本身的限制。还有一种说法是GET不能传body,所以我用express跑了个小服务。constexpress=require('express')constapp=express()app.use(require('express-body'))/*测试入口*/app.use('/test',(req,res)=>{res.send('这里是测试页面')})/*interface*/app.use('*',(req,res)=>{res.send(req.body)})app.listen('3000',()=>{console.log('expressstart')})然后我尝试在chrome中获取varmyHeaders=newHeaders();myHeaders.append("Content-Type","application/json");var原始=JSON。stringify({"hello":"world"});varrequestOptions={method:'GET',headers:myHeaders,body:raw,redirect:'follow'};fetch("localhost:3000",requestOptions).then(response=>response.text()).then(result=>console.log(result)).catch(error=>console.log('error',错误));果然,浏览器抛给我一个Theexception说GETorHEADrequestscannothaveabody。然后我用xhrvardata=JSON.stringify({"hello":"world"});varxhr=newXMLHttpRequest();xhr.withCredentials=true;xhr.addEventListener("readystatechange",function(){if(this.readyState===4){console.log(this.responseText);}});xhr.open("GET","http://localhost:3000/");xhr.setRequestHeader("内容-类型","应用程序/json");xhr.发送(数据);没想到请求发送了,返回的结果却是一个空的json。看了请求内容,确实没有body的影子,好像是在chrome中这个说法确实得到了验证,但是真的是这样吗?然后我用postman向服务发送了一个带body的GET请求,请求成功返回了我传过来的body信息,于是我又尝试用curl下curl--location--requestGET'localhost:3000'\--header'Content-Type:application/json'\--data-raw'{"hello":"world"}'也成功了,那这又是怎么回事呢?它可能与同源策略和浏览器的方言相同吗?于是搜索了一下,大概是在ToUseGet看到下面的说明的时候找到了下面的信息。我的英语不是很好。请自行翻译。按照惯例,当使用GET方法时,识别资源所需的所有信息都编码在URI中。HTTP/1.1中没有关于客户端在HTTP实体bo中向服务器提供数据的安全交互(例如,检索)的约定dy而不是在URI的查询部分。这意味着为了安全操作,URI可能会很长。安全操作的大参数的情况并没有直接由HTTP解决,因为它目前已部署。已经讨论了QUERY或“安全POST”或“GETwithBODY”方法(例如,在1996年12月的IETF会议上),但尚未达成共识。然后StackOverflow有这样一个问题HTTPGETwithrequestbody。GET请求消息中的负载没有定义的语义;在GET请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。对GET请求的响应是可缓存的;缓存可以使用它来满足后续的GET和HEAD请求,除非Cache-Control标头字段([[RFC7234]的第5.2节](https://tools.ietf.org/html/r...这么说吧,浏览器其实是遵守HTTP规范的,但是其他客户端也可以忽略这个规范,就算你通过了,你也可以通过也可以不通过。当然,协议建议你不要通过。。。如果你传过去,就不能保证幂等,不能等,就是说缓存没有意义。2.HTTP缓存在各种中文资料里经常说,协商缓存和强缓存我就不多说了。无法再验证来源。可能是为了方便大家了解缓存的特点。协议中没有这样的声明。给一个复杂的特征一个容易记住的名词是一种常见的做法,但它被传递了。还以为有这回事,然后看了看no-cache和no-store。这是no-cache的说明。“no-cache”响应指令指示响应不得用于满足未在源服务器上成功验证的后续请求。这允许源服务器阻止缓存使用它来满足请求而不联系它,即使缓存已配置为发送陈旧的响应。需要通过服务器验证来判断当前资源是否可以使用。“no-store”响应指令指示缓存不得存储即时请求或响应的任何部分。该指令适用于私有和共享缓存。“不得存储”在此上下文中意味着缓存不得有意将信息存储在非易失性存储中,并且必须尽最大努力在转发信息后尽快从易失性存储中删除信息。这意味着如果你不想使用缓存,你可以使用这个。所以一个误区是如果不想使用缓存,应该在Cache-Control3中使用no-store。在标签中挂上no-cache可以防止缓存页面吗?你应该总是使用各种文章中看到的,如何防止当前网页被缓存,最简单粗暴的方法是添加
