アカウント名:
パスワード:
Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org]
にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として Cache-Control: no-store を挙げていて、 プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0 を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。
今回の件が、このせいかどうかは分かりませんが、MDNを信じて情報漏えいが起
「no-store」でキャッシュするような CDN を使った時点で負けなんじゃないか?
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして https://engineering.mercari.com/blog/entry/2017-06-22-204500/ [mercari.com]
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは Cache-Control: private が含まれている場合のみとわかりました。
「場合のみ」とあるので、「no-store」じゃ駄目で「private」の必要があるとあります。CDN業者の名前は書かれていませんが、有名アプリのメルカリが使うような大規模なCDNでも、「no-store」無視の仕様だったりするのです。
また、
Expiresヘッダは、Cache-Controlヘッダにmax-ageまたはs-maxageがない場合採用されます。ただし、過去の日付である場合、0秒として扱われます。キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様に
まともな議論になってないから、遅ればせながら指摘するけど、“CDNが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもCDNに対するディレクティブではない。「Cache-Control」フィールド自体、CDNが無い時代に作られた。「Cache-Control: private」はCDNが無断借用しているだけ。CDNというのは、HTTP仕様としては違法や脱法的扱いのもの(違法改造)で、限定的に使われていたもの(動画配信やアップデート)が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。だから、 #4073928 の指摘は根本的に誤解に基づいている。#4073928 の最後にあるように、根本的に「マニュアル読め」が重要。それから、翻訳の場合は、原文も確認しておく。(もっとも、原文にミスがある可能性もある。)最近の個人的ミスは、 bash の日本語のマニュアルのバージョンが古かったことだった。
まあ、x86, amd64とかも魔改造だし、Unix, Linux は言うまでもなく、 httpだって魔改造したってね。。。「何!?この魔改造!?」って言えたら上級者だと思う。
日本国には「戦艦、戦車、戦闘機、兵隊は存在しない」このことは誰もが知っています。ところで、あなたの読解力と理解力は正常ですか。誤解していませんか。
質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの?
HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。
これは酷い。そもそも、ダイアルアップが主流の「インターネット」が高価だった時代は、キャッシュするプロキシの存在が一般的だったのじゃぞ。会社・学校などの組織がそれぞれプロキシを運用していたのじゃ。
例えば、児童・生徒・学生がパソコン室から20台で同じサイトを見たら帯域がもたないから、公開のプロキシサーバがキャッシュして1回ですむようにしていたのだ。
当時有名なのは Squid というプロキシで、1996年 (25年前)からあったのじゃぞ。
その後、利用可能な帯域幅が増えて、組織がプロキシサーバを持たなくなってきて、その後、常時SSL化(TLS化)の流れでキャッシュがしにくくなって廃れていったというのが歴史の流れ。
ということで、大昔から Cache-Control で共有キャッシュの制御は行われていたし、RFCにもそれを想定した記述が山ほどある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
MDN を信じずに「Cache-Control」には「private」を含めよう (スコア:1)
Web開発者がトップクラスとして信用しているサイトは MDN ですが、そこの Cache-Control の解説が酷いです。
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control [mozilla.org]
にっこりしている顔文字🙂 [mozilla.org] 付きの「良い例」として
Cache-Control: no-store を挙げていて、
プンスカしている顔文字😡 [mozilla.org] 付きの「悪い例」として
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
を挙げていますが、「良い例」の方だと今回のような漏洩事故の原因となります。
今回の件が、このせいかどうかは分かりませんが、MDNを信じて情報漏えいが起
Re: (スコア:0)
「no-store」でキャッシュするような CDN を使った時点で負けなんじゃないか?
メルカリの情報漏えいも「private」なら防げた (スコア:3, 興味深い)
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
https://engineering.mercari.com/blog/entry/2017-06-22-204500/ [mercari.com]
問題発覚後に切り替え後CDNのキャッシュの仕様を再度確認したところ、キャッシュをしないのは
Cache-Control: private
が含まれている場合のみとわかりました。
「場合のみ」とあるので、「no-store」じゃ駄目で「private」の必要があるとあります。
CDN業者の名前は書かれていませんが、有名アプリのメルカリが使うような大規模なCDNでも、「no-store」無視の仕様だったりするのです。
また、
Expiresヘッダは、Cache-Controlヘッダにmax-ageまたはs-maxageがない場合採用されます。ただし、過去の日付である場合、0秒として扱われます。キャッシュの有効期限が0秒となる場合、CDNからオリジンへのリクエストの処理中に、同じURLに対してリクエストが発生すると、最初のレスポンスを待って、2つ目以降のリクエストにも同じレスポンスが返される仕様に
皆さん誤解してます (スコア:0)
まともな議論になってないから、遅ればせながら指摘するけど、“CDNが”「Cache-Control: no-store」でキャッシュする仕様は正しい。そもそもCDNに対するディレクティブではない。「Cache-Control」フィールド自体、CDNが無い時代に作られた。「Cache-Control: private」はCDNが無断借用しているだけ。
CDNというのは、HTTP仕様としては違法や脱法的扱いのもの(違法改造)で、限定的に使われていたもの(動画配信やアップデート)が、スマホ・タブレットが普及したあたりから使うのが当たり前になったというものだと思う。
だから、 #4073928 の指摘は根本的に誤解に基づいている。
#4073928 の最後にあるように、根本的に「マニュアル読め」が重要。それから、翻訳の場合は、原文も確認しておく。(もっとも、原文にミスがある可能性もある。)
最近の個人的ミスは、 bash の日本語のマニュアルのバージョンが古かったことだった。
まあ、x86, amd64とかも魔改造だし、Unix, Linux は言うまでもなく、 httpだって魔改造したってね。。。「何!?この魔改造!?」って言えたら上級者だと思う。
日本国には「戦艦、戦車、戦闘機、兵隊は存在しない」このことは誰もが知っています。ところで、あなたの読解力と理解力は正常ですか。誤解していませんか。
Re: (スコア:0)
質問、CDNのどういうところがHTTPにとって違法あるいは脱法的なの?
HTTPにとってのCDNは https://datatracker.ietf.org/doc/html/rfc7230#section-2.3 [ietf.org] の"gateway" (a.k.a. "reverse proxy")に当てはまる存在であり、その存在自体に何か問題があるとは思っていなかったのだけど。
誤解しているのは「貴方」の方 (スコア:0)
これは酷い。
そもそも、ダイアルアップが主流の「インターネット」が高価だった時代は、キャッシュするプロキシの存在が一般的だったのじゃぞ。
会社・学校などの組織がそれぞれプロキシを運用していたのじゃ。
例えば、児童・生徒・学生がパソコン室から20台で同じサイトを見たら帯域がもたないから、公開のプロキシサーバがキャッシュして1回ですむようにしていたのだ。
当時有名なのは Squid というプロキシで、1996年 (25年前)からあったのじゃぞ。
その後、利用可能な帯域幅が増えて、組織がプロキシサーバを持たなくなってきて、その後、常時SSL化(TLS化)の流れでキャッシュがしにくくなって廃れていったというのが歴史の流れ。
ということで、大昔から Cache-Control で共有キャッシュの制御は行われていたし、RFCにもそれを想定した記述が山ほどある。