2018年04月19日に初出の投稿

Last modified: 2018-04-19

URL 正規化というのは、とりわけ SEO がオンライン・コンテンツの広告や宣伝でスコアが分散しないようにするための手法として着目されるようになった。それまでは、"http://www.markupdancing.net" のコンテンツと "http://markupdancing.net" のコンテンツに対するスコアが別々になっていたし、リクエストの FQDN が違えばコンテンツを分別してレスポンスできるのだから当然ではあるが、バラバラではもったいないという事情で、同じコンテンツには(少なくとも)同じ FQDN を対応させるという考え方になってきた。そして、そういう正規化を実施していることを canonical 属性でヘッダーに組み込むという手法も採用されている。

このような事情で、Apache を運用している多くのサーバ技術者は、VirtualHost の設定内容や .htaccess ファイルなどにおいて、特にリダイレクトのディレクティブを使ったり、mod_rewrite を使っている。しかし、こうした正規化を目的としたリダイレクトについて書かれた数多くのブログ記事やウェブページでは、説明の中でかなり致命的なポイントが欠落していると思う。それは、「HTTPS のプロトコルを前提にした FQDN の書き換えは、書き換え前と書き換え後のサーバ証明書をインストールしていない限り、原理的に不可能である」ということだ。当サイトはレンタルサーバで運営しているので、.htaccess で書いている内容を挙げると、以下のようになる(httpd の設定ファイルに書いても同じことだ)。

RewriteEngine On

RewriteCond %{HTTP_HOST} ^markupdancing\.net

RewriteRule (.*) https://www.markupdancing.net/$1 [R=301,L]

RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

このように書くと、http でのアクセスは全て https へ、www なしのアクセスは全て www ありという FQDN に正規化できる。しかし、これは自明ではない。レンタルサーバで、ちゃんと www ありの CN と www なしの CN という二つの(あるいはサブドメインに最初から対応できるようにワイルドカードの)証明書を使えるからだ。特に、

https://markupdancing.net/ から https://www.markupdancing.net/

というリダイレクトは、markupdancing.net という www なしの CN が許容されているサーバ証明書がなければ、必ずエラーになる。なぜなら、まずリクエストはウェブサーバで www なしの状態で暗号化通信が確立するかどうかを判定してから、URL の書き換えを処理するものだからだ。よって、www なしで正しくリクエストを処理できなくてはならず、多くのサーバで www ありのサーバ証明書しかインストールしていない状況だと、www ありの FQDN へリダイレクト処理する以前に、サーバへのリクエストが正しく処理されないのである。

ともかく、mod_rewrite や Redirect ディレクティブなどを生半可に解説している人は、

https://blog.dnsimple.com/2016/08/https-redirects/

のような記事でもじっくり読んでほしい。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook