Let’s talk about some of the big holes in the interview


Since I changed the company, I’ve been busy recruiting people in recent years. During the interview, I often dig a hole to see if others will jump inside
I haven’t written an article for a long time. Let’s sum up some experience by the way
I’m not sure if I can finish it. I’ll write as much as I can
Of course, the article only represents my personal point of view, I feel it’s not right

1. What is the difference between get and post requests

It’s a common problem. Some articles say that post is safer than get. To tell you the truth, it’s nonsense. The browser limits the length of get,

There is also a saying that get can’t be passed on to the body,
So I used express to run a small service

const express = require('express')
const app = express()

/*Test entry*/
app.use('/test', (req, res) => {
  res.send('test page here')

app.use('*', (req, res) => {

app.listen('3000', () => {
  console.log('express start')

Then I use it in chromefetchI tried

var myHeaders = new Headers();
myHeaders.append("Content-Type", "application/json");

var raw = JSON.stringify({"hello":"world"});

var requestOptions = {
  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', error));

Let's talk about some of the big holes in the interview
The browser threw an exception to me, saying that a get or head request cannot have a body

Then I use itxhrI tried

var data = JSON.stringify({"hello":"world"});

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function() {
  if(this.readyState === 4) {

xhr.open("GET", "http://localhost:3000/");
xhr.setRequestHeader("Content-Type", "application/json");


Unexpectedly, the request was sent out, but the result returned an empty JSON
Let's talk about some of the big holes in the interview
After reading the request content, there is really no shadow of the body
Let's talk about some of the big holes in the interview
It seems that this is true on chrome, but is it true?

Then I use itpostmanA get request with body was sent to the service
Let's talk about some of the big holes in the interview

As a result, the request successfully returned my body information
Let's talk about some of the big holes in the interview

So I tried curl again

curl --location --request GET 'localhost:3000' \
--header 'Content-Type: application/json' \
--data-raw '{

Let's talk about some of the big holes in the interview
And it worked

So what’s going on?
Is it the same as the homologous strategy and the dialect of the browser?
So I went to search and found the following informationwhenToUseGet
See the following instructions, my English is not good, you translate it

By convention, when GET method is used, all information required to identify the resource is encoded in the URI. There is no convention in HTTP/1.1 for a safe interaction (e.g., retrieval) where the client supplies data to the server in an HTTP entity body rather than in the query part of a URI. This means that for safe operations, URIs may be long. The case of large parameters to a safe operation is not directly addressed by HTTP as it is presently deployed. A QUERY or “safe POST” or “GET with BODY” method has been discussed (e.g., at the December 1996 IETF meeting) but no consensus has emerged.

Then stackoverflow has a problemHTTP GET with request bodyYou can take a look at the answers
There is a sentence in the agreement

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field ([Section 5.2 of [RFC7234]](https://tools.ietf.org/html/r…

That is to say, the browser actually abides by the HTTP specification, but other clients can ignore the specification. It’s OK to pass or not to pass. Of course, the protocol recommends you not to pass… If it is passed, it can’t guarantee idempotent, and it means that caching is meaningless

2. HTTP cache

I won’t say more about negotiation cache and strong cache in all kinds of Chinese materials. The origin of these two terms can’t be verified. Maybe it’s just for the convenience of everyone to understand the cache feature. There’s no such statement in the protocol. It’s a common practice to give a complex feature a noun that is easy to remember. However, it’s passed around and everyone thinks it’s true
Then take a lookno-cacheandno-store
This isno-cacheDescription of

The “no-cache” response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to
prevent a cache from using it to satisfy a request without contacting
it, even by caches that have been configured to send stale responses.

That is, the server must verify whether the current resource can be used
andno-storeDescription of

The “no-store” response directive indicates that a cache MUST NOT
store any part of either the immediate request or response. This
directive applies to both private and shared caches. “MUST NOT
store” in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile storage
as promptly as possible after forwarding it.

Generally speaking, if you don’t want to go, you can go this way
So a mistake is that if you don’t want to cache, you shouldCache-ControlGo insideno-store

3. Can no cache in the < meta / > tag prevent page caching?

You should often see in all kinds of articles that the simplest and most crude way to make the current web page not cache is to add

<meta http-equiv="cache-control" content="no-store" />
<meta http-equiv="Pragma" content="no-store" />
<meta http-equiv="expires" content="0" />

So I hung a page locally according to the above instructions
Let's talk about some of the big holes in the interview
On the second visit
When you think about it carefully, whether the HTTP protocol can go or not is determined by the request header. Before you get to the body layer, you have to decide whether to go or not. Besides, the server also needs to know that you send HTML text, and then analyze whether there is such a meta tag in it, and there must be corresponding fields in it, If it’s a JSP dynamic page, do you think this layer of interception is done in Apache or nginx?
So it can prove that this thing is invalid?
As a strict programmer, I can’t draw this conclusion so quickly. Although you copy all kinds of articles on the Internet, many things are not groundless
So I went to W3 to look through a large circle of information and found something for memeta
Let's talk about some of the big holes in the interview
It’s in html3.2, and then I’ll continue to turn back
As we all know, W3C gave up publishing HTML and DOM standards in 19 years, and whatwg became the dominant company
So I turned my head and continued to turn in whatwg

Let's talk about some of the big holes in the interview
Not at all

Then I ran and flipped

Let's talk about some of the big holes in the interview
Good guy, the only thing related to cache can’t be realized at all
So we have some conclusions. It’s not reliable, and it doesn’t work. What HTTP should do is http

4. Localstorage and sessionstorage

We usually talk aboutlocalStorageandsessionStorageI always talk about the volume. Generally speaking, it can only be used at most5MB,
But is that really the case?

Because I’m lazy, I went to a small website to test storage
Let's talk about some of the big holes in the interview
It’s about 5 megabytes in chrome,
Then I changed to safari, which is Apple’s own browser
Let's talk about some of the big holes in the interview
resultlocalStorageIt’s only five trillion,sessionStorageMore than 10 megabytes
The difference between browsers came out all of a sudden, which has nothing to do with the 5-megabyte mentioned above, but the 5-megabyte statement is definitely not groundless, so I went to W3 to see the agreement
W3: WebStorage

User agents should limit the total amount of space allowed for storage areas, because hostile authors could otherwise use this feature to exhaust the user’s available disk space.
User agents should guard against sites storing data under their origin’s other affiliated sites, e.g. storing up to the limit in a1.example.com, a2.example.com, a3.example.com, etc, circumventing the main example.com storage limit.
User agents may prompt the user when quotas are reached, allowing the user to grant a site more space. This enables sites to store many user-created documents on the user’s computer, for instance.
User agents should allow users to see how much space each domain is using.
A mostly arbitrary limit of five megabytes per origin is suggested. Implementation feedback is welcome and will be used to update this suggestion in the future.
For predictability, quotas should be based on the uncompressed size of data stored.

In order to prevent some developers with ulterior motives from exhausting the disk space on your computer, the volume of local storage resources is limited. However, more data can still be saved by changing the domain name. It is suggested that each source should be about 5 megabytes
Another suggestion… That is to say, it’s up to the client to do it. As long as you think it’s reasonable, you can do five g’s

Set and map

Generally commonSetWhat can we do? We should all say that it is used to de duplicate the array, but if the array is[{name: 1}, {name: 2}, {name: 3}, {name: 1}]In this case, we will dig two holes for the interviewer
useMapThe duck style of solving problems

const data = [{name:1}, {name:2}, {name:3}, {name:1}]
const maps = new Map()
data.forEach((item) => {
    maps.set(item.name, item)
const result = [...maps].map((item) =>item[1])

On the surface, it really solves the problem of literal quantity
However, once there are extra values in the object, there will be problems in the way mentioned above

The second is that set itself is a pointer problem

const a = {name: 1}
const b = {name: 2}
const c = Array.from(new Set([a, a, b, a]))

After we perform this operation, it will only appear[{name:1}, {name:2}]As a result,
So it’s not the object, it’s the pointer to the object
So if we can solve the pointer problem, maybe we can solve this problem,

Recommended Today

Implementation example of go operation etcd

etcdIt is an open-source, distributed key value pair data storage system, which provides shared configuration, service registration and discovery. This paper mainly introduces the installation and use of etcd. Etcdetcd introduction etcdIt is an open source and highly available distributed key value storage system developed with go language, which can be used to configure sharing […]