![[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダー](https://img.php.cn/upload/article/000/000/024/6321460b22905675.jpg)
非常に実践的な レスポンス ヘッダー、仕事で遭遇する問題を解決します。
問題を解決するだけでなく、バックエンドや運用保守と対立している場合に 優位に立つこともできます。
私の言うことが信じられないなら、下のシーンを見てください。見覚えがあるでしょうか?1. プレビューとダウンロードについて心配していますか?
txtFileSaver.js(または
現時点では、誰かが立ち上がって、urlなのですが、aタグで開くとプレビューになってしまいます…どうすればいいですか?保存してください!!!」
または「手書きの読書ストリームを名前を付けて保存」を推奨します。 その後、他の誰かがエコーしました...
私:? ? ?
#これは、コードを作成して解決する必要がある問題ですか? ![[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダー](https://img.php.cn/upload/image/828/988/572/1663124836224266.png "1663124836224266.png")
Content-Disposition
Response Header について学習した場合は、応答ヘッダーに 1 行追加するだけで問題を解決できることを知っているはずです。 1.2 はじめに
: この応答ヘッダーは、コンテンツが Preview# であるかどうかを決定します。 ## または ダウンロード。 これは 3 つの形式の値をサポートします:
url# に関連付けられています。 ＃＃ フォーマット。 Content-Disposition:attachment;filename="filename.jpg"
注: プレビューする必要がある場合は、使用するために適切な
おそらく、この目的のために、特別に
expressの小さな例を作成しました。
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)
}
2. プロジェクトはアップグレードされました。顧客はキャッシュをクリアする必要がありますか?
![[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダー](https://img.php.cn/upload/image/411/819/849/1663124846126876.png "1663124846126876.png")
「研究開発の担当者だけが理解できる」 操作を実行してください。問題を ブラウザ キャッシュ
に起因させないでください。 
したがって、Cache-Control 応答ヘッダーの使用方法を理解することは、フロントエンドにとって必須のスキルです。
2.2 概要
Cache-Control
属性は次のとおりです: これです!それでおしまい！それでおしまい！ 開発においては避けて通れない敷居であり、その存在価値はますます希薄になりつつありますが、既存の数多くのプロジェクトは技術動向によって消えることはなく、依然として価値があり、今後も活用していく必要があります。維持された。 システムの中核となる : サーバーによって割り当てられる応答ヘッダーで、ブラウザが Cookie 401 Cookie 」という現象については、サーバー側に問題がない場合、実際には であり、前回の ログインと同一人物ではないとみなします。 。 環境にいる場合は、 がドメイン制限を受けているかどうかを確認します <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…
名前に
hash
クッキー (結局のところ、コンテンツが変更されると、名前の ハッシュ
も変更されます) ## を通じて導入されたすべてのサードパーティ ライブラリのバージョン情報を保持することをお勧めします。 #cdn/xx/xx/jquery.min.js は
jquery@3.6.0/dist/jquery.min.js に切り替わります) Any html not beキャッシュまたはnegotiatecacheなどの固定名のファイルは推奨されます。
がこんなにかわいいわけがない!
3.1 シナリオ
「チュン兄弟、ログインは成功したのに、リクエストが依然として
401 なのはなぜですか?"
cookie に預けた値を取得できないのはなぜですか?」
cookie は壊れていますか?ブラウザでは明らかに価値があるのに、なぜアクセスできないのですか?」
という応答ヘッダーについて聞いたことがありますか?」私:「兄弟、そうですか?」持っていますか? ![[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダー](https://img.php.cn/upload/image/177/689/695/1663124856730779.png "1663124856730779.png")
cookie3.2 はじめに
Cookie
はかつて ## でした#Web そして、set-cookie 応答ヘッダーは、最初の主役です。 Set-Cookie を生成し、Cookie を制限できるようにします。 さまざまな機能。 これらの機能には次のものが含まれます:<ul>
<li>有効期限;<code>Expires=<date></date>
Max-Age=<number></number>
無効な Cookieそれまでに経過する秒数。 0 または -1 は直接的には無効です。この属性は Expires よりも高い優先度を持ちます。 ドメイン=cookie のみを生成できるドメインを指定します; (この属性ではワイルドカードが許可されます)は主にセキュリティのために使用されます) Path=<path-value></path-value>
は Domain よりも詳細な制御戦略であり、さらに指定します Cookie は、xx パスでのみ送信できます。 Https でのみ生成; Secureset-cookie ヘッダーに Secure 属性がある場合そうすると、ブラウザは Https 環境で Cookie のみを生成して送信します。 js オペレーション API; HttpOnly
If set-cookie has HttpOnly header 属性を使用すると、Cookie 属性の生成、読み取り、書き込み、送信はブラウザーによって「応答ヘッダー」を通じてのみ制御され、フロントエンドは操作できなくなります。 js Cookie を介して。 SameSite=<samesite-value></samesite-value>
サポートされる属性には、Strict、Lax、 None は、それぞれ次のことを意味します:
Strict: ドメイン間での移動はまったく不可能; Lax: ナビゲーションのみを許可外部サイトから発信する場合は、Cookie
を指定します: クロスドメインも許可され、制限はありません。
3.3 開発に関するよくある質問の分析
Web フロントエンド? が使用されていました。たとえば、Spring MVC プロジェクトでは、Cookie に ## が与えられています。 #JSeesionId の値は、現在のセッションに参加しているかどうかを判断するための識別として使用されます。 「ログインしているのにブラウザがCookieを保存していない可能性があります。 。 言い換えれば、リクエストを開始するたびに、サーバーはあなたが Secure 属性を一時的に削除する必要がある場合があります。
, パス制限があるかどうか , 存在するか HttpOnly? 確認してください一つずつ降りてください、問題を解決するのは難しくありません。
以上が[編集と要約] フロントエンドが知っておくべきいくつかの実用的な応答ヘッダーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
