[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダー

この記事を読むと、次の内容が得られます:

• 非常に実践的な レスポンス ヘッダー、仕事で遭遇する問題を解決します。

• 問題を解決するだけでなく、バ​​ックエンドや運用保守と対立している場合に 優位に立つこともできます。

応答ヘッダーを学ぶことは重要ですか?

#本当に重要です。

私の言うことが信じられないなら、下のシーンを見てください。見覚えがあるでしょうか?

1. プレビューとダウンロードについて心配していますか?

1.1 シナリオ

同僚から何度か聞いたことがあります。 、グループの友人がこの問題について議論しました:

「バックエンドは

txt

(または pdf/'json' など) ファイルのダウンロードを提供します url なのですが、a タグで開くとプレビューになってしまいます…どうすればいいですか?保存してください!!!」

現時点では、誰かが立ち上がって、

FileSaver.js

または「手書きの読書ストリームを名前を付けて保存」を推奨します。 その後、他の誰かがエコーしました...

私:? ? ?

#これは、コードを作成して解決する必要がある問題ですか?

Content-Disposition

Response Header について学習した場合は、応答ヘッダーに 1 行追加するだけで問題を解決できることを知っているはずです。 1.2 はじめに

Content-Disposition

: この応答ヘッダーは、コンテンツが Preview# であるかどうかを決定します。 ## または ダウンロード。 これは 3 つの形式の値をサポートします:

Content-Disposition: inline

• 現時点では、メッセージ本文はページまたはページ全体の形式で表示されます。 (プレビュー)

  
  

  Content-Disposition:attachment
• メッセージ本文をダウンロードする必要があり、デフォルトのファイル名は

  url# に関連付けられています。 ＃＃ フォーマット。
  Content-Disposition:attachment;filename="filename.jpg"

メッセージ本文をダウンロードする必要があり、デフォルトのファイル名を指定できます。

• 
  注: プレビューする必要がある場合は、使用するために適切な

  Content-Type
を一致させる必要があります。 ##1.3 例

この目的のために、特別に express の小さな例を作成しました。

おそらく、

express アプリケーションの下に次のように 3 つのルートを作成しました。

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)
}

次に、3 つのルートをそれぞれ訪問すると、効果は異なりました。

2. プロジェクトはアップグレードされました。顧客はキャッシュをクリアする必要がありますか?

2.1 シナリオ

実装: 「顧客からのフィードバック

バグ はまだ修正されていません。」 あなた: 「兄弟、それは問題です。」本当に修正されました。お客様にキャッシュをクリアするように依頼してみてはいかがでしょうか?」

実装: 「ああ? お客様はキャッシュをクリアしないと言っています...」

...

顧客がそれを行うとは決して期待しないでください。

「研究開発の担当者だけが理解できる」 操作を実行してください。問題を ブラウザ キャッシュ
に起因させないでください。

ブラウザ キャッシュ

は、ユーザーの邪魔をするためではなく、ユーザー エクスペリエンスを最適化するために発明されました。

したがって、Cache-Control 応答ヘッダーの使用方法を理解することは、フロントエンドにとって必須のスキルです。

2.2 概要

Cache-Control

: キャッシュ メカニズムを指定するために使用されます。

キャッシュは、フロントエンドの 8 部構成のエッセイの必須知識として、誰もがよく知っていると思います。 共通の

Cache-Control

属性は次のとおりです: <table> <thead><tr class="firstRow"> <th>応答ヘッダー属性</th> <th>値</th> <th>意味</th> </tr></thead> <tbody> <tr> <td>キャッシュ制御</td> <td>no-store</td> <td>キャッシュなし。これにより、クライアントもサーバーもキャッシュされなくなり、いわゆる強力なキャッシュやネゴシエートされたキャッシュは存在しません。 </td> </tr> <tr> <td>cache-control</td> <td>public</td> <td>応答を任意のオブジェクト (リクエストを送信するクライアント、プロキシ サーバーなど) によってキャッシュできることを示します。 、など）、通常はキャッシュできないコンテンツであっても。 (例: 1. この応答には max-age ディレクティブまたは Expires ヘッダーがありません。2. この応答に対応するリクエスト メソッドは POST です。) </td> </tr> <tr> <td>cache-control</td> <td> private</td> <td> は、応答を共有キャッシュとしてではなく、単一のユーザーによってのみキャッシュできることを示します (つまり、プロキシ サーバーは応答をキャッシュできません)。プライベート キャッシュは、たとえばユーザーのローカル ブラウザに対応する応答コンテンツをキャッシュできます。 </td> </tr> <tr> <td>cache-control</td> <td>max-age=</td> <td>キャッシュ保存の最大期間を設定します。この期間を過ぎると、キャッシュは期限切れとみなされます (単位秒)。 Expires とは対照的に、時間はリクエストの時間に相対的です。 </td> </tr> </tbody> </table> <ul> <li>キャッシュなし<br>キャッシュなしが最も理解しやすく、すべてのリクエストはキャッシュなしでサーバーから再取得されます。 <br>この戦略には、<code>Cache-Control: no-store 応答ヘッダーを指定するだけで済みます。

強力なキャッシュ
一部のリソース ファイルはほとんど変更されず (ハッシュ名が付けられたファイルなど)、ローカル キャッシュから直接取得できます。 -called Strong Cache ;
cache-control: public/private または cache-control: max-age= 。

ネゴシエーション キャッシュ

これはより複雑なキャッシュ メカニズムであり、応答ヘッダー
を介して単純かつ粗雑に実装することはできなくなり、代わりにフロントエンドとバックエンドのコラボレーションが必要になります。 。 簡単に言うと、リソースがリクエストされるたびに、フロントエンドは前の応答 ハッシュ
を書き込み、サーバー リソースが変更されたかどうかを尋ねますキャッシング効果です。 この記事では詳細については説明しません。興味があれば、この記事を参照してください: juejin.cn/post/703078…

2.3実際の制作にどのように適用するか?

名前に

hash
• 値を持つリソースはすべて強力にキャッシュできます。 (結局のところ、コンテンツが変更されると、名前の ハッシュ
  も変更されます) ## を通じて導入されたすべてのサードパーティ ライブラリのバージョン情報を保持することをお勧めします。 #cdn
。これにより、強力なキャッシュも有効になります。
• (たとえば、/xx/xx/jquery.min.js は
  jquery@3.6.0/dist/jquery.min.js に切り替わります) Any html
、
• ico not beキャッシュまたはnegotiatecacheなどの固定名のファイルは推奨されます。
3. 私の

クッキー

がこんなにかわいいわけがない! 3.1 シナリオ

「チュン兄弟、ログインは成功したのに、リクエストが依然として

401

なのはなぜですか?"

「チュン兄弟、

cookie

に預けた値を取得できないのはなぜですか?」

「チュン兄弟、チュン兄弟、この

cookie

は壊れていますか?ブラウザでは明らかに価値があるのに、なぜアクセスできないのですか?」

私:「兄弟、そうですか?」持っていますか?

set-cookie

という応答ヘッダーについて聞いたことがありますか?」

これです!それでおしまい！それでおしまい！ cookie

に関するあらゆる種類の異常は、すべてこれに依存しています!

3.2 はじめに

Cookie

はかつて ## でした#Web

開発においては避けて通れない敷居であり、その存在価値はますます希薄になりつつありますが、既存の数多くのプロジェクトは技術動向によって消えることはなく、依然として価値があり、今後も活用していく必要があります。維持された。 そして、set-cookie 応答ヘッダーは、

Cookie

システムの中核となる 最初の主役です。 Set-Cookie

: サーバーによって割り当てられる応答ヘッダーで、ブラウザが Cookie を生成し、Cookie を制限できるようにします。 さまざまな機能。 これらの機能には次のものが含まれます:<ul> <li>有効期限;<code>Expires=<date></date>

Lifetime;Max-Age=<number></number>
無効な Cookieそれまでに経過する秒数。 0 または -1 は直接的には無効です。この属性は Expires よりも高い優先度を持ちます。

ドメイン名;ドメイン=
cookie のみを生成できるドメインを指定します; (この属性ではワイルドカードが許可されます)は主にセキュリティのために使用されます)

Path; Path=<path-value></path-value>
は Domain よりも詳細な制御戦略であり、さらに指定します Cookie は、xx パスでのみ送信できます。

Https でのみ生成; Secure
set-cookie ヘッダーに Secure 属性がある場合そうすると、ブラウザは Https 環境で Cookie のみを生成して送信します。

Disablejs オペレーション API; HttpOnly
If set-cookie has HttpOnly header 属性を使用すると、Cookie 属性の生成、読み取り、書き込み、送信はブラウザーによって「応答ヘッダー」を通じてのみ制御され、フロントエンドは操作できなくなります。 js Cookie を介して。

クロスドメイン移植性が許可されるかどうか; SameSite=<samesite-value></samesite-value>
サポートされる属性には、Strict、Lax、 None は、それぞれ次のことを意味します:

• Strict: ドメイン間での移動はまったく不可能;
• Lax: ナビゲーションのみを許可外部サイトから発信する場合は、Cookie
• ##None を指定します: クロスドメインも許可され、制限はありません。

3.3 開発に関するよくある質問の分析

• ログインに成功したのに、リクエストが次のようになったのはなぜですかまだ

  401?

  多くの初期のプロジェクトでは、ユーザー識別の手段として

  Cookie が使用されていました。たとえば、Spring MVC プロジェクトでは、Cookie に ## が与えられています。 #JSeesionId の値は、現在のセッションに参加しているかどうかを判断するための識別として使用されます。 「ログインしているのに

  401

  」という現象については、サーバー側に問題がない場合、実際にはブラウザがCookieを保存していない可能性があります。 。 言い換えれば、リクエストを開始するたびに、サーバーはあなたが

  新しいセッション

  であり、前回の ログインと同一人物ではないとみなします。 。

  http

  環境にいる場合は、Secure 属性を一時的に削除する必要がある場合があります。

入金または出金ができない場合
• まずは

  がドメイン制限を受けているかどうかを確認します
  , パス制限があるかどうか , 存在するか HttpOnly? 確認してください一つずつ降りてください、問題を解決するのは難しくありません。
  

(学習ビデオ共有:

Web フロントエンド

)

以上が[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。