[Compilation and Summary] Several practical response headers that the front-end must know

Read this article, you will:

• Learn a few super and super practical Response headers, solve the problems you encounter at work.

• Not only solves the problem, but also gives you the upper hand when you are at odds with the backend and operation and maintenance.

Is it important to learn response headers?

It’s really important.

1. Are you worried about previewing and downloading?

1.1 Scenario

"The backend provides a

txt (or pdf/'json', etc.) file downloadurl, but when I open it with the a tag, it turns into a preview... What should I do? Save!!!"

FileSaver.js or "Save handwritten reading stream as".

Content-Disposition Response Header, then you must know that the problem can be solved by just adding a line to the response header.

1.2 Introduction

Content-Disposition: This response header can determine whether the content is Preview Or download.

• Content-Disposition: inlineAt this time, the message body will be part of the page or Displayed in the form of the entire page. (Preview)
  

• Content-Disposition: attachmentThe message body should be downloaded, and the default file name is related to the
  url format.

• Content-Disposition: attachment; filename="filename.jpg"The message body should be downloaded, and the default file name can be specified.
  

Note: If you need to preview, you need to match the appropriate

Content-Type for consumption;

To this end, I specially wrote a

small example. I probably wrote three routes under the

application, as follows:

const user = {
  name: "摸鱼的春哥",
  blogUrl: "https://juejin.cn/user/1714893870865303"
}

const contentDispositionInline = async (req, res, next) => {
  res.setHeader('Content-Disposition', 'inline')
  res.send(user)
}

const contentDispositionFilename = async (req, res, next) => {
  res.setHeader('Content-Disposition', 'attachment; filename="chunge.json"')
  res.send(user)
}

const contentDispositionNoFilename = async (req, res, next) => {
  res.setHeader('Content-Disposition', 'attachment')
  res.send(user)
}

Implementation: "Customer feedback

is still not fixed." You: "Brother, it’s really fixed How about you ask the customer to clear the cache?"Implementation: "Ah? The customer said he won't clear it..."
...

Never expect your customer to do it. Perform operations that

. Don't attribute your problem to browser cache either.

was invented to optimize user experience, not to hinder users. Therefore, understanding how to use the

response header is a must-know skill for the front-end.

Cache-Control: Used to specify the caching mechanism. Caching, as a required knowledge for front-end eight-part essays, I believe everyone is familiar with it. Common

Cache-Control attributes are as follows:

• No caching
  No caching is the easiest to understand. Every request will be re-obtained from the server without any caching.
  This strategy only needs to be given the Cache-Control: no-store response header.
• Strong Cache
  Some resource files will almost never change (such as files that have been hash-named), which can be obtained directly from the local cache. This is the so-called Strong cache ;
  You can specify the mechanism as strong cache through cache-control: public/private or cache-control: max-age= .
• Negotiation Caching
  This is a more complex caching mechanism that can no longer be implemented simply and crudely through the response header . Instead, it requires front-end and back-end collaboration.
  Simply put, every time a resource is requested, the front end will write the previous response hash and ask the server whether the resource has changed, so as to achieve accurate caching effect. .
  This article will not go into details. If you are interested, you can refer to this article: juejin.cn/post/703078…

2.3 How to apply it in actual production?

• Any resource whose name has a hash value can be strongly cached.
  (After all, once the content changes, the hash of the name will also change)
• It is recommended to carry version information for all third-party libraries introduced through cdn , which can also enable strong caching.
  (For example, /xx/xx/jquery.min.js switches to [email protected]/dist/jquery.min.js)
• Any html, ico It is recommended that files with fixed names such as not be cached or negotiate cache.

3. My Cookie can’t be so cute!

3.1 Scenario

"Brother Chun, why is it that my login is successful but the request is still 401?"

"Brother Chun, why can't I get the value I deposited into cookie?"

" Brother Chun, Brother Chun, is this cookie broken? It’s obviously valuable in the browser, why can’t I access it?"

Me: "Brother, do you have it? Have you ever heard of a response header called set-cookie?”

That’s it! That's it! that's it! All kinds of anomalies about cookie, all rely on it!

3.2 Introduction

Cookie used to be Web It is a threshold that cannot be bypassed in development, and now its existence is getting weaker and weaker, but the large number of existing projects will not disappear due to technological trends. They are still valuable and still need to be maintained.

And the set-cookie response header is the core first protagonist of the Cookie system.

Set-Cookie: is a response header, assigned by the server, allowing the browser to generate Cookie and limit Cookie various features.

These features include:

• Expiration time limit;Expires=
• Lifetime;Max-Age=
  Invalid cookie The number of seconds to elapse before. 0 or -1 is directly invalid; this attribute has a higher priority than Expires.
• Domain name;Domain=
  Specify the domain in which cookie can only be generated; (Wildcarding is allowed, this attribute is mainly used for For security)
• Path; Path=
  is a more detailed control strategy than Domain, and even specifies Cookie can be sent only under the xx path.
• Only generated in Https; Secure
  If there is Secure attribute in the set-cookie header, then The browser will only generate and send Cookie in the Https environment.
• Disablejs Operation API; HttpOnly
  If set-cookie has HttpOnly in the header attribute, then the generation, reading, writing, and sending of the Cookie attribute can only be controlled by the browser through the "response header", and the front end is no longer allowed to operate through js Cookie.
• Whether cross-domain portability is allowed; SameSite=
  Supported attributes include Strict, Lax, None, respectively means:
  • Strict: cannot be carried across domains at all;
  • Lax: only allows navigation from external sites. When originating, carry Cookie
  • ##None: cross-domain is also allowed, no restriction.

3.3 Analysis of Development Frequently Asked Questions

• Why did you log in successfully but the request was still

  401?

  Many early projects used

  Cookie as a means of user identification. For example, the Spring MVC project is by giving Cookie a ## The value of #JSeesionId is used as identification to determine whether you are in the current session. As for the phenomenon of "Logged in, but still

  401

  ", if there is no problem on the server side, it is probably that the browser does not actually store Cookie. In other words, every time you initiate a request, the server thinks that you are a

  new session

  , and you are not the same person as the last login. If you are in a

  http

  environment, you may need to temporarily remove the Secure attribute.

Can’t deposit or withdraw?
• First confirm whether

  is subject to domain restrictions
  , Whether there are path restrictions , Are there HttpOnly? Check one by one Come down, the problem is not difficult to solve.
  

(Learning video sharing:

The above is the detailed content of [Compilation and Summary] Several practical response headers that the front-end must know. For more information, please follow other related articles on the PHP Chinese website!