例3: 認証無しの共有ページなので、接続数を減らしつつ、変更の反映はすみやかにしたい 先のフローチャートにやりたいことを矢印で追記すると、以下のようになります。 このやりたいことについて、判断ごとの条件を書き出すと、以下のようになります。 A判断 – キャッシュを多少は使って接続数を減らしたいほしい。(no-cacheおよびno-storeは使えない) B判断 – リアルタイムで反映される必要はないので、反映まで1分ぐらいは待てる。(キャッシュ期間は短めにする必要があるので、仮に30秒でmax-age=30) C判断 – 通信失敗時は前回のデータで表示した方が良い。(no-store、must-revalidate、proxy-revalidateはどれも使わない) Ｂ判断の指定だけになるので、案外シンプルで、Cache-Controlヘッダーは、以下のようになります。 例4: 顧客情報を

ディレクティブは、,(カンマ)で区切って、複数指定が可能です。 例えば、max-age=3600とmust-revalidateの2つのディレクティブを指定するときは、以下のように書きます。(ディレクティブの個々の意味は、後ほど説明するので、まだ解らなくて大丈夫です。) ただし、複数指定する場合は、矛盾しないように指定する必要があります。(矛盾する組み合わせの動作は未定義なので) そして、互換性のため、ブラウザやプロキシが未対応のディレクティブは、無視する決まりがあります。この動作のおかげで、古いブラウザは新しいディレクティブを無視できるので、ブラウザがおかしくなることは防げます。 RFCやMDNにも、この説明の例として、互換性のため、類似効果のディレクティブを並記する例が書かれていたりします。 ですが、この方法で、古いシステムとの互換性を考え出すとどんどん複雑になります。 現実的に考えて

「304 Not Modified 」に対応すると、同じデータを送らなくなるので、通信量が削減できます。 参照を3回繰り返した場合の例を、検証ありの「304 Not Modified ステータス」を使った動きに書き換えたのが、以下の図です。 通信回数は減っていませんが、データの送信は最初の1度だけで、通信量が大きく減っています。 このように、「304 Not Modified 」をうまく使えば、短いキャッシュ期間の問題を軽減しつつ、通信コストや処理時間も節約できるのです。 Webアプリ側の「304 Not Modified」の処理 とても都合が良さそうな「304 Not Modified 」ですが、ブラウザだけが対応してもだめで、WebサーバおよびWebアプリが対応しないと機能しません。 WebサーバおよびWebアプリが「304 Not Modified」に対応する場合、具体的には、以下の

Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont

Send feedback Preparing for the end of third-party cookies Stay organized with collections Save and categorize content based on your preferences. If your site uses third-party cookies, it's time to take action as we approach their deprecation. To facilitate testing, Chrome has restricted third-party cookies for 1% of users from January 4th, 2024. Chrome plans to ramp up third-party cookie restrict

Kaigi on Rails 2023の登壇資料です！

本章では、HTTP/3がTCPに代わって下位層で用いるQUICについて解説します。 QUICはトランスポートプロトコル QUICはトランスポートプロトコルです。QUICの説明に入る前に、トランスポートプロトコルついておさらいします。 TCP/IPの4階層モデル プロトコルは階層で役割を分担しています。TCP/IPの4階層モデルでは、アプリケーション層、トランスポート層、インターネット層、ネットワークインタフェース層に分かれます（図1⁠）⁠。 図1　TCP/IPの4階層モデル アプリケーション層に分類されるアプリケーションプロトコルは、クライアントやサーバで動作するアプリケーションの動作に関するデータやメッセージの通信ルールを規定します。たとえばSMTP（Simple Mail Transfer Protocol）は、メールを送信する通信ルールを規定しています。HTTPはこの層に属します。

2024年7月に、ICANNで .internal トップレベルドメイン(TLD) がプライベート用途として予約されたようです。 背景 長らくプライベート用途で利用できるトップレベルドメインについて議論されてきました。 現在、各組織が独自のTLDをプライベート用に利用しているケースがあります。しかし以下のような問題があります、 新gTLDが登録された際に、衝突する可能性がある Root DNSへ不要な問い合わせがある 実際、.home、.internal、.lan、.corp、.localdomain、.dlink、.zyxel-usg のような問い合わせがRoot DNSに来ていることが知られています。 そこで、.internal をプライベート用途として予約しようというのが、ICANNで議論されている『SAC113：SSAC私的利用TLDに関する勧告（SAC113）』です。 JPNIC

この記事は以下の記事を参考にして書かれています。英文のブログですが内容をより詳しく理解したい場合はこちらのブログもご参照下さい。 https://www.fastly.com/blog/best-practices-using-vary-header https://www.fastly.com/blog/getting-most-out-vary-fastly 特に記載がない限り本記事の記載内容は Fastly のデフォルト設定での挙動となります。 Fastly の正式なサポート内容ついては以下のドキュメントをご参照下さい。 サポートページ: https://docs.fastly.com/ 日本語(一部のみ): https://docs.fastly.com/ja/ この記事の内容について HTTP の Vary ヘッダーは正しく利用すると非常に便利な HTTP ヘッダーですが、間違っ

簡単な開発をしたいときにちょっとだけ Cookie を使いたいときがあると思う。私は日頃から Web 標準な何かをするときはライブラリを使うことに抵抗があり、Cookie 周りの操作もライブラリを使わずにやりたい。が、そんなちょっとカッコ良い発言をしている裏で、私はこっそり「Cookie 付けるのってどうするんだっけ？」「Cookie のフォーマットってどんなんだっけ？」といつも Google で調べている。もちろん Set-Cookie くらいは覚えているが、「順番は？どういうデリミタで？どういうパーサーが必要で？」というのは結構忘れているし、意外と皆さんもすっとは出てこないのではないだろうか。あ、私だけですか、すみません。。。と、私は毎回調べているが、毎回調べるのはめんどくさいのでメモを書いておこうと思う。 OGP は クッキーに見せかけた空気だ。「こいつ最近 OGP でふざけてるし、

『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse

TLS は Transport Layer Security の略で、盗聴、あるいは通信相手のなりすましの可能性がある通信路において、安全に通信を行うための暗号通信プロトコルです。 本書では、Go 言語を使って TLS サーバ・クライアントを用意し、その通信を Wireshark で観察しながら、TLS のプロトコルについて説明します。 本書を読むことで、TLS の通信で実際にどのようなパケットが送受信されているかが確認でき、TLS の学習の助けになると思います。 また、TLS には複数のバージョンがありますが、本記事では、最も広く使われており、かつ最新である TLS1.3 に焦点を当てます。

「マスタリングTCP/IP を読んだけど理解がイマイチ進まない。Goがどのようにサーバーを立てているのか気になる。」 そんなスキマを埋めるための本です。 Goの標準パッケージである net package を一切利用せずに、自作TCP/IPプロトコルでサーバーを作ります。 パケットをどのようにやり取りするかハンズオン形式で解説し、最後にToDoリストAPIを実装します。

作成日 2023-05-31 更新日 2023-06-02 author @bokken_ tag well-known, appsec はじめに パスワード変更のためのURLを示すための、A Well-Known URL for Changing Passwords という仕様が存在する。¶ この仕様は主にクライアントサイドのパスワード管理ツールで使われる想定の仕様だ。¶ 本記事ではこの仕様がどういうものか、どういった利点があるのかについてまとめる。¶ パスワード管理ソフトとその課題 パスワード管理ツールはクロスサイトでのパスワードの再利用を防いだり、オートフィルをしてユーザビリティを高めてくれる良いツールだ。 ブラウザにもパスワード管理ツールが搭載されていたり、有名どころでは1PasswordやBitwardenのようなツールがある。¶ これらのツールの中にはパスワードの強度を教えてく

セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい！」とフラグを...。 cats_dogs開発者のヒラマツです。 HTTPキャッシュをうまく使う技術、HTTPキャッシュ制御を解説します。 HTTPキャッシュは、WebアプリなどのWebサービスの通信を最適化する技術です。 HTTPのCache-Controlヘッダーの使い方の話でもあります。 HTTPキャッシュ制御と言っても、Cache-Controlヘッダーの設定だけなので、簡単そうに思えます。 しかし、正しく設定しようとすると、案外、複雑で苦労します。 また、理解なしに使うと、情報漏えいの問題を起こす可能性もあり、適当に設定するのは危険です。 ぜひ、この文章を読んで、理解した上で、Catch-Controlを設定してください。 cats_dogsの仕様を書くときに、

はじめに 先日、 Linuxで動かしながら学ぶTCP/IPネットワーク入門 を読了ならびに実装しました。 こちらの本は下記に関して内容がわかりやすく記述されており、入門としてとても良い本でした。 データリンク層におけるイーサネットを通るフレームの挙動 TCP/IP の挙動 アプリケーション層のプロトコル (HTTP / DHCP / NAT) socket 通信 しかし、上記の本を進める中でソケット通信の内容が詳細には分からず、少しもどかしい気持ちになってしまいました。 分からなかった部分としては以下のようなものです。 そもそも socket とはなにか Server で accept() したときに新しい socket を生成しているようだがこれはなにか Server で最初に作成した socket() と同じものなのか それともクライアント用の socket なのか Server の

Chrome 113 で、 DevTools の Network ペインで HTTP ヘッダを好きなように編集して、いろんな状態をお試しできるようになっている。 What's New in DevTools (Chrome 113) - Chrome Developers で紹介されている。 GitHub から example.com を fetch してみる GitHub の CSP ヘッダを上書き example.com の CORS のヘッダを上書き 途中で指定したフォルダの中身は何？ 上書きをやめるには？ 感想 GitHub から example.com を fetch してみる 試しに、 CSP で外部への通信がそれなりに制限されている GitHub から、 example.com への fetch を成功させてみる (外部サイトへの通信は、認証情報や秘密の情報の漏洩などに気をつ

TLSの有無 言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2] デフォルポート httpは80、httpsは443です。[3][4] 権威性 以降の説明に入る前に前提を確認します。本稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。 Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5] どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではな

はじめに 最近Denoをよく触っており、DenoのSSRフレームワークであるFreshのミドルウェア・キャッシュについて調べている際にブラウザキャッシュのEtagヘッダが使用されており、気になったのでブラウザキャッシュの仕組みについて調べてみました。 Etagの正体 Etagとは、ブラウザキャッシュの仕組みの中で使用されるHTTPレスポンスヘッダーでリソースの特定のバージョンに関する識別子のことです。 Etagがあることでウェブサーバーは、コンテンツが変更されていない場合はレスポンス全体を再送する必要がないので、キャッシュがより効率的になる。 ブラウザキャッシュの設定について ブラウザキャッシュを設定する際に必要なHTTPレスポンスヘッダーはEtagを含めて以下の通りです。 Expiresヘッダー Cache-Controlヘッダー Last-Modifiedヘッダー Etagヘッダー そ