ドメインが初めて正規登録

 サイトに関する問題については、ご自分でサイトを作っている方や、サイト作成などの仕事をなさっている方以外の大半の方々にとっては、余り興味はないかと思います。しかしわたしの体験は、健全なWEBの運用を推進するための有益な資料の一つになると思いますので、少し長文になるかと思いますが、ご報告させていただきます。

ドメインが初めて正規登録

実は今回のサイト(サーバー)移転は、費用を安くしたいという思いもありましたが、それ以上に、きちんとしたところでドメインを管理してもらいたいというのがそもそもの動機でした。

Xサーバーでは、一部不可解なことはあったものの、さほど大きな問題は発生していません。しかし管理料無料ゆえなのかどうか、ドメイン管理は全く納得できませんでした。ドメインの登録情報であるWhois情報の公開方法はどことも、自分で公開するか、管理会社に公開代理を委託するかの二通りがあるのですが、自分の個人情報を公開したくない場合は代理公開にします。

わたしは、ドメイン登録に関する個人情報も公開したいので、代理公開を選ばず、自分で公開する、を選択しました。結果、確かにドメインに関するわたしの個人情報は、日本国内でのWhois情報には記載されていました。しかしXサーバーの名前がどこにもなく、Technical(技術担当)の名前までわたしの名前になっています。

ドメインのテクニカルなど全く分かりませんし、ドメイン管理の実務を担うはずのXサーバーの関与はどこにも記載されていません。全てわたし個人の責任になるような記載がなされています。驚いてXサーバーに問い合わせたところ、テクニカルをXサーバーにする場合ば、Xサーバーに公開代理(=わたしの個人情報は非公開)を選択する必要があると言われました。

「kasuri-ikat.com」を管理してもらっているさくらインターネットでは、公開代理ではなく、自分で公開する方法を選択しても、Technicalなども含めて管理に関わる項目には、さくらインターネットの名前や住所や担当部署などの情報もきちんと記載されています。

しかしXサーバーでは、公開代理を委託すると、わたしの名前も含めて個人情報は全て非公開になる仕組みになっています。Xサーバーに代理公開を委託してわたしの個人情報を全て非公開にするか、Xサーバーのドメイン管理に関する責任を一切明示せず、ドメイン管理に関する責任を自分で担って個人情報を公開するか、この二者択一を迫られましたが、わたしは迷わず、個人情報公開を選びました。

しかしこの公開は日本国内向けの限定的なものでしかありませんでした。というのは、Xサーバーに移転後のドメイン情報を、ドメイン管理の国際組織であるICANNに登録するのは、わたしが自分でしなければならないという仕組みになっていたからです。

自分で公開を選択すると、テクニカルも自分で担当しなければならないということです。代理公開を選択しても、わたしの個人情報は非公開ですので、自分でICANNに登録するかどうか迷いましたが、事情の分からない素人が操作して、もしも間違った情報がICANNに登録されたら、それこそ悲劇です。それでICANNには登録せぬまま。

これはXサーバーの通常のドメイン管理のスタイルなのか、あるいは無料ゆえなのか、事情は分かりませんでしたが、Xサーバーのドメイン管理の余りの無責任さに怒りを覚ええまして、更新はしないと移転早々からひそかに心に決めていました。

とはいえ、Xサーバーからのドメインの移転手続きは、ロック解除の手続きが済むと、あとはまさにワンクリックで完了。移転先のさくらでもワンクリック。移管が完了するまで8日もかかったことは想定外のことでしたが、わたしはこの間、ただ待つだけ。ドメイン移管に複雑怪奇、かつ膨大な作業を次々と強要してきたGMOとは大違い。GMOの異常さに改めて怒りを覚えた次第です。

GMO、ドメイン移管を妨害
GMOの不正とICANN情報
GMOのあくらつ商法 
GMOの対応の異常さ

ドメイン管理をさくらに移管して初めて、ashi-jp.comドメインは、Whois情報に記載されるステーサス(ドメインの状態)がOKになりました。このドメインは2015年1月にGMOで登録しましたが、GMOからはWhois情報の確認は皆無でしたので、Whois情報そのものを知らずにきたのですが、この仕組みを知って以来、ずっとロック状態。

GMOではロック解除を何度要求しても拒否され続けてきました。Xサーバーでは、自分でロック解除ができる仕組みにはなっていましたが、ロックを解除すると勝手に移管されるかもしれないとの忠告を受けていましたので、やむなくロックを維持。

しかしさくらに移管したところ、初めてロックは解除され、ステータスは「OK」!。

さくらのドメイン管理に関する上位組織であるレジストラ(ICANNから認定を受けたドメイン登録事業者)の、JPRSのWhois情報では、登録者(=所有者)であるわたしの名前がドメインの次に明確に記載されています。
さくらのWhois情報検索も非常に分かりやすい表示になっています。
上記リンク先で、「ashi-jp.com」を入力して検索すると、Whois情報が表示されます。

どちらも住所はさくらインターネットの住所になっていますが、さくらが全責任を持ってくれそうなので、これはこのままでいいかなとも思っています。

さらなる大変化は、ICANNのWhois情報に、初めてわたしの名前が記載されたことです。
ICANN LookUpで「ashi-jp.com」を検索するとWhois情報が表示されます。「Registrant:」(ドメイン登録者)としてわたしの名前が記載されていますが、「Technical:」(技術担当)も「Administrative:」(ドメイン管理者)情報もきちんと記載されています。

ICANNにわたしの名前のみならず、ドメイン情報が全てきちんと記載されたのも初めてですが、これもさくらに移管してからのことです。これで初めて、ashi-jp.comのドメインの登録者(所有者)がわたしであることが、国内外に明確に示されたことになります。

数あるドメイン管理業者の中では、さくらインターネットのように、ドメイン登録事業者(レジストラ)としてICANNから正式に認定されている、JPRSのような事業者と提携しているところは非常に少ないのではないかと思います。

GMOのレジストラは、当初は、見聞きしたこともないアメリカの業者でしたが、わたしの批判が始まると、自社の子会社のお名前ドットコムに変更しましたが、どちらもICANNには認定されていません。Xサーバーは、こちらも聞いたこともないスタードメインという会社でした。管理料無料だったからかどうかは不明。

わたしは、さくらにドメインを移管するまで延々と続いた、ドメインをめぐる不可解事に悩まされる中で、このドメインはわたし以外の誰かが陰の登録者(所有者)になっているのではないかと、疑うようになりました。

「kasuri-ikat.com」のドメイン管理を委託しているさくらインターネットは、ICANNからドメイン登録事業者として認定されているJPRSと提携していることからも分かるように、同社のドメイン管理は非常に公正であることは実感していました。

「ashi-jp.com」もさくらに管理を委託すれば、このドメインの背後事情も明らかになるのではないかと思っていました。GMOがこのドメインの登録者(所有者)がまるでわたしではないかのような不可解きわまる対応を続けてきた背後事情、例えば、真の登録者はわたしではないというような事情、その場合はわたしの名前では登録できないということにはなりますが、ともかくも背後事情は明らかになるのではないかと期待していました。

しかし無事わたしの名前で、国内外で正式に登録されました。これはわたしにとっては非常に喜ばしい結果ですが、この結果は、GMOが一貫して登録者であるわたしの権利を無視し続けたことをあらためて明確にしました。

サイト被害というと一般的には、情報の盗み出しやサイトの改竄が大半だと思いますが、わたしのように無名に近いドメインが狙われるという例は余りないのではないか。おそらく皆無だろうと思います。

有名な一流企業や著名人の名前=ドメイトは、「名前=ドメイト」だけでも価値がありますが、ほぼ無名に近いドメインの場合は、サイトの内容がドメインの価値を決めるはずです。ashi-jp.comもサイトの内容が改ざんされるという被害は皆無です。

狙われるのはもっぱらドメインのみということは、このドメインの価値はわたしが発信し続けているサイトの内容に、その価値の源泉があることを意味しているのだと思います。そのせいなのかどうか、ドメインをめぐる不可解事のほかに、データベースにも訳の分からないデータが多数含まれていました。

樹海のようなデータベース

データベースはWordPressを特徴づける仕組みで、頻繁に更新される投稿記事などを齟齬なく管理することを可能にしている機能ですが、素人がその全貌を把握するのは簡単ではありませんでした。

初めてデータベースを目にしたときは、データの樹海かと驚愕したほどです。それほど何か複雑極まりない印象を受けました。しかし障害が発生するたびに、必死で仕組みを学ぶということを繰り返すうちに、樹海にも規則性のあることが分かってきました。規則性のあることが分かれば、徐々に視界も開けてきます。視界が開けてくると、樹海のようなデータの中には、ゴミのようなデータや、正体不明のデータもひそんでいることも分かってきました。

XサーバーにWPサイト(ashi-jp.com)を移転するときには、自動移転の仕組みを使って、瞬間移動をしました。(HTMLサイトのold.ashi-jp.comとkasuri-ikat.comは、仕組みは単純ですので手動で移転。)

自動移転は素人には非常に便利な方法ですが、後に、多少仕組みが分かってくると、瞬間移動では、移転時のデータの様子はブラックボックスだということに気がつきました。移転先でデータを確認すればいいわけですが、全自動というのは、その設定にはこちらは関与できません。というか、関与する必要はないわけです。

しかし多少は仕組みが分かってきた今思うのは、全自動という仕組みは素人には非常にありがたく、かつ基本的には非常に安全でもあるものの、その反面、全自動下の動きは外部者にとっては完全にブラックボックス同然であるということです。

こうした感想も、わたし自身の体験からきています。実は昨年、全自動でWPのサイトデータをXサーバーに移転した際、WP関係のデータを保存したフォルダーには、自動的に「1」という番号が付されていました。ところが移転完了との表示が出ているにもかかわらず、そのフォルダーの中は空でした。

あら、おかしいなあと思いましたが、自動移転すれば簡単なので、再度データを移したところ、自動付番ですので数字は「2」とつきました。データベース名にもこの数字がついていました。データベースには最初の「1」も並んでいましたが、中は空です。当時は何かの手違いだろうと思って気にも留めずそのまま使い続けてきましたが、今振り返ると、単純な手違いではなかったのではないかとも思われてきます。

というのは、データベースにはいくつかの不可解事が発生していたからです。

不可解事の一つは、削除したはずのテーマに関連したテーブルが多数残っていたことです。テーブルとは、基本的には表を表す言葉ですが、データベースのテーブルとは、重層的な構成をなす様々な機能をもつファイルを格納する、保管庫のようなものです。お使いになったことのない方には分かりにくいかもしれませんが、テーブルは、機能の異なる各ファイルの独立性を保つ役目も担っています。

WordPressには、基本的は12個のテーブルで構成されていますが、今年の4月か5頃に確認した際には、基本の4倍ぐらいのテーブルが並んでいました。各テーブルを開くと重層的にデータが並んでいますが、中には空のももあり。(テーブルの実例は膨大ですので、最下段に掲載してリンクも貼っています。)

過剰なテーブルの大半はプラグイン(拡張機能アプリ類)関連のようですが、中にはなぜ入っているのか不明のものもありました。

その一つは、今年1月の始め頃まで使っていたcocona(コクーン)関連のものです。昨年2020年1月に、cocoonから現在のLuxeritas(ルクセリタス)にテーマ(テンプレート)を変えましたが、データベースまでは確認していませんでした。

実はXサーバーの契約期限が6月30日ですので、移転前に、データの整理をしようと思い、データを調べ始めたところ、何かよく分からないデータがたくさん並んでいることが分かりました。しかしどれが必要でどれが不要かの選定は簡単ではありません。

基本は12本だとはいえ、基本以外全て削除しても大丈夫なのか、この見極めにはかなりな時間を要しました。バックアップを取ればすぐに復元できるとはいえ、その境地に達するまでには本当に時間がかかりました。

サイトに変化はないかを確認しながら徐々に削除していきました。まず最初に削除したのは、optionsというテーブルに格納されているcoconaのテーマです。しかし表に並んでいるcocona関連の5本のテーブルは消えずに残っています。

cocoonの前に使っていたcenoteというテーマは、テーマを変更した以外、データベースから削除するという作業は全くしていませんが(データベースが何なのかさえ分かっていない頃でもありましたが)、データベースのどこにもそのかけらすら残っていません。

しかしcoconaはテーマ本体を削除したにもかかわらず、関連のテーブルが残っているのはなぜなのか。テーブルの中には空のものもありましたが、下層に大量のデータが含まれているものもありますので、一気に削除する決断はできませんでした。そうこうするうちに、さらに不可解なものを目にしました。

何度もデータベースを開いてデータを調べていた時のことです。ふとデータベースのアドレスが目に入りました。これまでデータベースのアドレスをそれとして見たことはありませんでしたが、アドレスの中に「cocoon_function」という文字が入っていました。

わたしのデータベースIDも含まれていたものの、なぜその後ろに「cocoon_function」という文字が入っているのか、不可解至極です。Xサーバーに尋ねたところ、以前、「cocoon」を使っていたからではないかとの回答が届きました。

しかし使っていたテーマ名が入るのであれば、cenote やLuxeritasの文字も入るはずではないかと思いましたが、そこまでの質問はしませんでした。代わりに、データベースの状況についてLuxeritasに尋ねてみました。

しかしいずれについても、他のテーマのことは分からないので、WordPress.orgフォーラムで聞いてみてと言われました。加えて、XサーバーからもWordpress.orgフォーラムに尋ねることを奨められていました。

そこでWordpress.orgフォーラムで質問しようとしたのですが、WPの使用登録しているメールアドレスやローマ字表記の名前のいずれを使っても、利用可能にはならず、やむなく登録済みとは少し変えたローマ字表記名を入力しましたが、それもはねられました。

やむなく、本名を漢字入力するとその後の手続きは進んだのですが、質問記入ページに表示された名前は全く見知らぬ名前になっています。「葦の葉ブログ」サイトに関する質問ですので、別人の名前が表示されていたならば、ドメインのみならず、サイトそのものの所有権や著作権の真偽にまで関係してきますので、見も知らない名前で質問するわけにはいきません。

WordPress.orgフォーラムは基本は英語なので、日本語(漢字)表記が文字化けしたのかとも思いましたが、質問欄に表示された名前と右上に小さく表記された会員IDに記された漢字表記の名前が、さらに別人の名前になっています。質問者の名前と会員名とが異なった名前で表示されるという複雑さ。

色々操作しましたが、わたしの名前が正しく表示されないと分かった以上、WordPress.orgフォーラムで質問することは非常に危険ですので、質問することは止めました。

WPでの不可解な動きは、いくらWPがオープンソースで誰もが登録すれば、ソースコードにアクセス可能とはいえ、事前の準備なしには不可能です。

ここまでくると、自分で判断するしかないと覚悟しました。覚悟といえば大げさですが、「cocoon」のテーブルを全て削除しました。冷静に考えると当然ですが、削除してもサイト表示には何の影響もありませんでした。

しかしデータベースのアドレスに並ぶ「cocoon_function」という文字は残ったままですが、このアドレスは、データベースを登録すると自動的に付与されるものなので、気持ち悪いと思いつつもそのままにしておりました。

その後、この件はわたしの関心外に退き忘れておりましたが、サーバー移転直前にふとこの件を思い出してURLを確認したところ、「cocon_function」という文字は消えていました。

移転直前に確認したものがもう一つあります。サーバーの動きを制御する「.htaccess」という、重要な役目を担うファイルですが、開いてびっくり!ここにも「cocoon」という文字が並んでいたからです。その文字列も一番下にご紹介しております。

なお「cocoon」関連の記載は、「cocoon」創設者の方が関与したとは露考えておりません。「cocoon」を騙った勢力による仕業だと思っていますが、健全で公明、公正なネット運用、WP運用が実現することを願って、本ブログでは様々な事象を事実として報告させていただいております。

ところで、もう一つ、「cocoon」以外の正体不明者がいました。「usces」のついた、最下段に掲示しています7本のテーブルですが、こちらは、ネットで調べたところ、「welcart」というECサイトで使われているタグらしい。あるいは別のECサイトのものかもしれませんが、いずれにせよ、わたしはWPにECを導入したことはありません。

葦書房の本を直販しようとBASEというECサイトに登録したことはありますが、WPのECは決済などの安全面に問題があるとのことだったので、WPでは使ったことはありません。そもそも葦書房の既刊の在庫本の販売には、ECサイトは似合いませんので、BASEも登録しただけで使っていません。

にもかかわらず、ECサイトのテーブルが並んでいるのはなぜなのか、不可解です。

以上のように、「葦の葉ブログ」のサイトをめぐっては、ドメインも含めて不可解なことだらけ。一部は削除しましたが、抜本的な大掃除はサイト移転時に実施することにしました。ファイルを手動で移転することにしたのは、そのためでした。この大掃除で、不要なファイルやデータを大胆に削除。すっきりしました。

大容量データといえば、バックアップ用プラグイン、All-in-One WP Migrationは超異常なほど容量を食います。これは異変の類ではありませんが、サーバーに保存されているバックアップデータを削除すると、サーバー使用量が10分の1ぐらいにまで激減。このプラグインを使っている方はこまめに削除しましょう。

もう一つの変化についても一言。旧葦の葉ブログの各ブログページは、移転後は「.html」を付加せずとも表示されるようになりましたが、アドレスに拡張子「.html」が表示されないという状況には変化はありません。

さくらに尋ねたところ、さくらではアドレスに拡張子がなくてもサイトページは表示される仕組みになっているとのことでした。非表示にならなければ、アドレスの異変には気がつかないはずですので、前回のさくら利用中から拡張子はなかったのかどうかは不明ですが、Xサーバーに移転後もある時期までは表示されていた記憶があります。

サーバー移転後は全サイトで無事表示されるかどうか、必ず何度も確認していますので、移転直後から非表示ならば、すぐに気がつくはずですので、非表示になったのは、Xサーバー移転後のことだと思います。

Windowsにはファイルの拡張子を表示/非表示(ファイル識別に不便なのに、なぜ非表示がデフォルトなのか!)にする設定があるのですが、わたしは表示設定にしていますし、Windowsの設定はWindowsに保存しているファイルにのみ適用されるはずですので、Windowsには原因はないはずです。

不思議といえば不思議ですが、さくらでドメインを登録して管理もさくらに委託している「kasuri-ikat.com」の「絣ラボ」は、サーバーの移転前も後も一貫して拡張子は表示され、サイトも全ページ表示されています。

同じHTMLサイトなのに、この違いは何に起因するのかは大きな謎です。当然、自然発生的な現象ではありません。実は旧葦の葉ブログの各ページファイルの拡張子は「htm」と「html」という「l」一文字の有無による2種類の拡張子が混在しています。どちらも同じ属性をもつファイルですが、URLを手動入力した場合、両者統合の設定をしていないと、たった「l」一文字の有無で表示されないことになります。

わたしはある時期まで「htm」を使っていましたが、後に「html」を使うようになりましたので、両者が混在しています。プロのサイト作成者はほぼ「htm」を使うことはありませんが、わたしはかなり長期に渡って「htm」を使ってきました。両者の混在はその名残りですが、拡張子の非表示でその名残りも見ることはできません。もちろん、サーバーには拡張子の違いそのままで全ファイルが保存されていますが、アドレスには表示されません。

とまあ、不可解な事象は完全に解消したわけではありませんが、6年余り使ってきたドメイン「ashi-jp.com」の登録者(所有者)として初めて、わたしの名前(久本福子)が公式に国内外で認知されたことは、今回の移転の最大の収穫です。

ドメインも正規に登録されたので、久々にGoogle広告の掲載設定をしたのですが、なんとトップページに巨大な広告が二つも掲載されて、公開したばかりのコロナと政治の私物化の目次が見えない状況になっていました。しかもその一つが「お名前ドットコムの広告」です。

すぐさま設定を変えようとしたのですが、「試験期間中なので7月19日まで変更も削除もできない」という趣旨の、これまで見たこともない表示が出て、操作ボタンは全てグレイアウトしてビクとも動きません。 

新しい仕組みなのかと思い、やむなく19日まで待ちました。しかし20日になっても自由に操作ができないばかりか、今度は「試験期間中なので89日間変更も削除もできない」という表示に変わっていました。

さすがにおかしいと思って、あれこれ操作しているうちにやっと編集可能になり、全てを停止しました。後になって気がついたのですが、今回の広告再掲時にはGoogle広告や検索関係のコードはサイトからは全て削除したままでした。にもかかわらず、デカデカと広告が掲載されていました。現在は全て削除しています。この広告に邪魔されて未読の方は、コロナと政治の私物化もご覧ください。

他にも関連する事象について書きたいことは山のようにありますが、移転関連だけでもかなり長文になりましたので、時間ができたら書くことにいたします。

わたしは、ドメインが狙われるという、ほぼ前例のない特殊な被害にさらされていますので、今後とも注意を怠らず、サイト運営を続けたいと思います。艱難辛苦は人を鍛えるという格言を身をもって体験してきましたが、おそらくこの厳しい鍛錬は今後も続くものと思います。わたしにとっては、新型コロナよりも厳しい環境です。

なお、「1」でご紹介したJPRSのサイトに、「駅街ガイド.jp」という、各地の様子を調べる際に非常に便利な案内サイトがありますのでご紹介します。

5年前の熊本地震で被害を受けた阿蘇神社の拝殿が復旧され、7月12日に竣工祭が行われたそうです。阿蘇神社のHPに掲載されている震災直後の写真を見ると、よくもここまで復興したものだと、関係者の方々のご苦労がしのばれます。(阿蘇神社

<<資料>>

移転前のデータベース

actionscheduler_actions
actionscheduler_claims
actionscheduler_groups
actionscheduler_logs
aioseo_notifications
aioseo_posts
aiowps_events
aiowps_failed_logins
aiowps_global_meta
aiowps_permanent_b
cocoon_access
cocoon_afflieiate_tags
cocoon_function_texts
cocoon_item_rankings
cocoon_speach_balloons
commentmeta
comments
ewwwio_images
ewwwio_queue
inks
options
postmeta
posts
statistics_exclusions
statistics_historical
statistics_pages
statistics_search
statistics_useronline
statistics_visit
statistics_visitor
termmeta
terms
term_relationships
term_taxonomy
tm_taskmeta
tm_tasks
usces_access
usces_log
usces_member
usces_member meta
usces_order
usces_ordercart
usces_order_meta
usermeta
users

「.htaccess」内のcocoon関連記載箇所(文字化けもそのまま)

#BEGIN COCOON HTACCESS

# ETags(Configure entity tags) 、オサ・ケ、・゚ト・

<ifModule mod_headers.c>

Header unset ETag

</ifModule> 

 FileETag None

# Enable Keep-Alive 、゚ト・

<IfModule mod_headers.c>

Header set Connection keep-alive

</IfModule>

# MIME Type トノイテ

<IfModule mime_module>

AddType text/cache-manifest .appcache

AddType image/x-icon .ico

AddType image/svg+xml .svg

AddType application/x-font-ttf .ttf

AddType application/x-font-woff .woff

AddType application/x-font-woff2 .woff2

AddType application/x-font-opentype .otf

AddType application/vnd.ms-fontobject .eot

</IfModule>

# ・ラ・愠ッ・キ・ュ・罕テ・キ・螟ホタ゚ト遙ハイ霖・ネ・ユ・ゥ・ネ、ュ・罕テ・キ・蝪ヒ

<IfModule mod_headers.c>

#1ヌッ・ュ・罕テ・キ・蝪ハCSS。ヲJavaScript、ハ、ノ、マ。「・ッ・ィ・遙シ、ト、ア、ニ、、、・ォ、餔K。ヒ

<FilesMatch “\.(css|js|ico|jpe?g|png|gif|svg|swf|pdf|ttf|woff|woff2|otf|eot)$">

Header set Cache-Control “max-age=31536000, public"

</FilesMatch>

# ・ラ・愠ュ・キ・オ。シ・ミ。シ、ャエヨー网テ、ソ・ウ・ニ・ト、ロノロ、キ、ハ、、、隍ヲ、ヒ、ケ、・

Header append Vary Accept-Encoding env=!dont-vary

</IfModule>

# ・ヨ・鬣ヲ・カ・ュ・罕テ・キ・螟ホタ゚ト・

<IfModule mod_headers.c>

<ifModule mod_expires.c>

ExpiresActive On

# ・ュ・罕テ・キ・蠖魘・ス。ハ1ノテ、ヒタ゚ト遙ヒ

ExpiresDefault “access plus 1 seconds"

# MIME Type 、エ、ネ、ホタ゚ト・

ExpiresByType text/css “access plus 1 year"

ExpiresByType text/js “access plus 1 year"

ExpiresByType text/javascript “access plus 1 year"

ExpiresByType image/gif “access plus 1 year"

ExpiresByType image/jpeg “access plus 1 year"

ExpiresByType image/png “access plus 1 year"

ExpiresByType image/svg+xml “access plus 1 year"

ExpiresByType application/pdf “access plus 1 year"

ExpiresByType application/javascript “access plus 1 year"

ExpiresByType application/x-javascript “access plus 1 year"

ExpiresByType application/x-shockwave-flash “access plus 1 year"

ExpiresByType application/x-font-ttf “access plus 1 year"

ExpiresByType application/x-font-woff “access plus 1 year"

ExpiresByType application/x-font-woff2 “access plus 1 year"

ExpiresByType application/x-font-opentype “access plus 1 year"

ExpiresByType application/vnd.ms-fontobject “access plus 1 year"

</IfModule>

</IfModule>

# Gzipーオスフ、ホタ゚ト・

<IfModule mod_deflate.c>

SetOutputFilter DEFLATE

# クナ、、・ヨ・鬣ヲ・カ、ヌ、マフオク・

BrowserMatch ^Mozilla/4\.0[678] no-gzip

BrowserMatch ^Mozilla/4 gzip-only-text/html

BrowserMatch \bMSIE\s(7|8) !no-gzip !gzip-only-text/html

# イ霖・ハ、ノーオスフコム、゚、ホ・ウ・ニ・ト、マコニーオスフ、キ、ハ、、

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico|eot|woff|woff2)$ no-gzip dont-vary

AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE text/js

AddOutputFilterByType DEFLATE image/svg+xml

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/rss+xml

AddOutputFilterByType DEFLATE application/atom_xml

AddOutputFilterByType DEFLATE application/javascript

AddOutputFilterByType DEFLATE application/x-javascript

AddOutputFilterByType DEFLATE application/x-httpd-php

AddOutputFilterByType DEFLATE application/x-font-ttf

AddOutputFilterByType DEFLATE application/x-font-opentype

</IfModule>

#END COCOON HTACCESS

WordPress