sonic64.com

2006-02-21 (Tue)

* Accept-Encoding に gzip を付けてないクライアントをリダイレクト

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [Apache] [http] [sonic64.com]

アクセスログを見ていたら、503 Service Temporarily Unavailable が出ていることに気づいた。503 はサーバ側の都合でサービスができないことを意味する HTTP ステータスコード。要するに、503 が出ている間は当サイトにアクセスできなかったということだ。

ログによると、最近アクセスが多かったようで一日20GB を超える転送量が続いていた模様。中でも全記事全文入りの RSS である cl-full.xml の転送量が90%を占めていた。おそらくこれのせいでさくらインターネットの転送量制限を超えてしまい、503 となっていたのだろう。

cl-full.xml は過去の全記事全文入りで 4MB を超えるサイズだから、サイト全体の転送量が増えても仕方がないかもしれないけど、ちょっと多い感じがする。だれかの役に立つかもしれないから公開しているのでどんどん使ってもらって構わないのだが、サイトのサービスの妨げになるのは困る。仕方がないので制限をかけることにした。

- 制限をかける

2005-09-15 の「mod_rewrite でリクエストに応じて gzip 圧縮ファイルを返す」では、mod_gzip を使えない当サイトの環境でも Accept-Encoding: gzip を送ってきているクライアントには gzip 圧縮したデータを返すようにした。今回はそれを一歩進めて、リクエストされたファイルが cl-full.xml でかつ Accept-Encoding: gzip がない場合、HTTP レスポンスコード 302 Moved Temporarily を返して、数十キロバイト程度でサイズの小さい cl.xml へリダイレクトする。

リクエストに Accept-Encoding: gzip がある場合は今まで通り gzip 圧縮した cl-full.xml を返す。

- Accept-Encoding に gzip を付けてないクライアントをリダイレクトする mod_rewrite の RewiteRule

単純にリダイレクトしてるだけ。

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} cl-full\.xml$
RewriteCond %{HTTP:Accept-Encoding} !gzip
RewriteRule .+ http://sonic64.com/cl.xml [L,R]

リダイレクトせずに cl.xml の中身を返すようにすることもできるけど、「君はこっちのコンテンツを使ってね」というリダイレクトの意図が伝わりにくいので使わない。でも、それだったら Vary を付ける方がいいかなあ。

- HTTP トランザクションの中身を見て確認

2005-04-16 で書いた「Live Http headers - HTTP ヘッダ表示ツール」で HTTP トランザクションの中身を表示して確認する。

以下のように、 Accept-Encoding: gzip つきならそのままアクセス許可。

http://sonic64.com/cl-full.xml

GET /cl-full.xml HTTP/1.1
Host: sonic64.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.x 200 OK
Date: Mon, 20 Feb 2006 04:43:35 GMT
Server: Apache/1.3.34 (Unix)
Last-Modified: Mon, 20 Feb 2006 02:33:38 GMT
Etag: "339758-fab0f-43ebfb82"
Accept-Ranges: bytes
Content-Length: 1026831
Keep-Alive: timeout=3, max=8
Connection: Keep-Alive
Content-Type: application/xml
Content-Encoding: gzip

以下のように、Accept-Encoding に gzip を付けてないクライアントは 302 を返して cl.xml へリダイレクト。
まず、Accept-Encoding に gzip なしのクライアントがリクエストしてくるとする。

GET /cl-full.xml HTTP/1.1
Host: sonic64.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://sonic64.com/
Pragma: no-cache
Cache-Control: no-cache

302 を返して cl.xml へリダイレクト。

HTTP/1.x 302 Found
Date: Mon, 20 Feb 2006 04:46:02 GMT
Server: Apache/1.3.34 (Unix)
Location: http://sonic64.com/cl.xml
Keep-Alive: timeout=3, max=7
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

302 を受けたクライアントは cl.xml にリクエスト。

GET /cl.xml HTTP/1.1
Host: sonic64.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html; q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Mon, 20 Feb 2006 02:33:30 GMT
If-None-Match: "339172-24c4-43ebfb7a"

もちろん Accept-Encoding: gzip などはリクエストにないが、cl.xml はそういったリクエストの場合は圧縮していないコンテンツを返すだけなので、無事レスポンスが返される。

HTTP/1.x 304 Not Modified
Date: Mon, 20 Feb 2006 04:46:02 GMT
Server: Apache/1.3.34 (Unix)
Connection: Keep-Alive, Keep-Alive
Keep-Alive: timeout=3, max=6
Etag: "339172-24c4-43ebfb7a"

これでよしと。

2006-01-10 (Tue)

* rsync と ssh でミラーリングアップロード

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [ssh] [ネットワーク] [sonic64.com]

当サイト Landscape - エンジニアのメモのコンテンツのアップロードに、rsync を使うようにしてみた。

使ってみると、rsync は実に良くできた便利なツールであることがわかった。ちなみに今までは lftp を使っていた。詳しくは 2004-05-08 の「lftp を使った ftp ミラーリングと便利機能」を参照。さくらインターネットを使う前までは ftp しか許可されていなかったので仕方がないが、もっと早くから rsync に切り替えるべきだった。

- rsync でミラーリングアップロード

以下のコマンドで、ローカルで生成済みの Landscape のコンテンツをリモートのさくらインターネットのサーバに転送している。

rsync -t -r -z --include=*.html* --exclude=* -e "ssh -i $HOME/.ssh/sonic64.com_upload" $HOME/public_html/log.sonic64/ sonic64@sonic64.com:/home/sonic64/www/sonic64

コマンドの意味。
-t はファイルのタイムスタンプを転送先に反映させる。
-r はディレクトリを再帰的に転送する。
-z は圧縮を有効にする。

--include=*.html* --exclude=* はとりあえずあらゆるファイルとディレクトリを転送の対象外にして、その後 .html の拡張子を持つファイルのみ明示的に転送を許可している。要するに html だけ転送しているわけだ。$HOME/public_html/log.sonic64/*.html を転送対象に指定してもいいのだが、ファイル数が多すぎるために引数が長すぎるというエラーになってしまう。それを回避するため、$HOME/public_html/log.sonic64/ を転送対象として指定してから --include=*.html* --exclude=* で対象を *.html に絞っている。もっと上手いやり方もあると思うが、とりあえずこれで。

-e は ssh を使って接続を構成する。暗号化や公開鍵暗号による認証を利用できる。

ちなみに、ローカルに存在しないファイルをリモートから削除したい場合は、--delete オプションを指定する。私の場合はリモートにのみ存在するファイルやディレクトリがあるし、Landscape のコンテンツは増える一方で減ることはまずないので指定していない。

- rsync のデータ圧縮

rsync ではデータの圧縮をサポートしている。圧縮を使う場合は -z を指定する。テキストファイルを一気にミラーリングする場合などは、転送量を三分の一程度に減らすことができる。

$ rsync -W -v -t -r -z --include=*.html* --exclude=* -e "ssh -i $HOME/.ssh/sonic64.com_upload" $HOME/public_html/log.sonic64/ sonic64@sonic64.com:/home/sonic64/www/sonic64

sent 13460480 bytes received 17636 bytes 45457.39 bytes/sec
total size is 43120469 speedup is 3.20

13460480 バイトしか送信していないのに、合計サイズが43120469 バイトになっている。これは圧縮の恩恵だ。

私の使っている回線のアップロード速度は、理論値で 512Kbps。実際の速度はだいたい秒間50KB くらいになる。 Landscape のコンテンツは合計で50MB 弱。圧縮せずに転送すると単純計算で1000秒、すなわち17分弱かかることになる。圧縮を有効にするだけで、17分が6分程度に短縮される。これは非常に便利だ。

ちなみに、-W オプションは後述する「rsync アルゴリズム」を無効にするためのオプション。今回は圧縮による速度向上度合だけを計測したいので -W を指定したが、私の平常時の運用では指定していない。-v は詳細な転送情報を表示するためのオプション。

- rsync アルゴリズムと転送量の削減

rsync は独自の rsync アルゴリズムを使ってデータ転送量を削減している。しかもこれは圧縮と組み合わせることができる。

rsync アルゴリズムの良いところは、ファイルを一定サイズごとのブロックに分割して必要なブロックだけを転送している点にある。大きなファイルの一部分だけが変更されたとしても、変更を含むブロックだけを転送すればよいことになり、転送量を減らすことができる。

P2P ファイル共有ソフトの Winny でも類似の機能を実装している。2005-11-29 の「Winny の技術を読了」には詳しく書かなかったが、Winny はダウンロードに失敗しても、最初からダウンロードをやり直す必要はない。Winny は共有ファイルを64KB ごとのブロックに区切り、そのブロック単位でデータをやりとりするからだ。これと同じようなもの。

以下は記事を追加してミラーリングを行った場合。

$ rsync -v -t -r -z --include=*.html* --exclude=* -e "ssh -i $HOME/.ssh/sonic64.com_upload" $HOME/public_html/log.sonic64/ sonic64@sonic64.com:/home/sonic64/www/sonic64

sent 1771974 bytes received 389842 bytes 40407.78 bytes/sec
total size is 43182507 speedup is 19.98

今の Landscape の HTML は、新規記事が追加されるとサイドバーに新規記事へのリンクなどが追加されるため、全ファイルが更新される。ftp だったら全ファイルを再アップロードする必要があるところだが、rsync は全ファイルの全データ分を転送するという挙動を見せていない。送っているのは 1771974 バイトだけ。ブロックの差分だけ転送している結果だ。このおかげで、通常の 19.98 倍という速度を達成している。素晴らしい。

ローカル生成 + サーバへ一括転送という仕組みのツールなら rsync は非常に有用だ。記事数2000くらいまでなら、今の仕組みのままでも大丈夫そうだ。rsync にはもっといろんな機能があるだろうから、しばらくは man rsync をじっくり読んでみることにする。

2005-11-02 (Wed)

* sonic64.com の転送量の80%が RSS

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [sonic64.com] [Apache] [ネットワーク] [RSS]

当サイト Landscape が infoseek isweb から移転して sonic64.com を使うようになってから、1か月ほど経った。というわけでアクセスログを見てみる。

- Landscape - エンジニアのメモ 2005年10月のアクセス

総ページビューとか、人気のあったページとかはまあどうでもいいんだけど、いちおうメモ。ページビューは372969。約37万。Webalizer によるページビューなので、今までとはカウント方法が異なっている可能性はある。

月間総転送量は 63557488KB。約60GB、一日あたり2GBというところか。なんだか減ってる気がする。旧サイトを置いていた infoseek isweb では、多いときで一日5GB、少ないときで1GBくらいだったと思う。平均すると一日あたり 3GB から 4GB くらいだったかな。移転後に転送量が減ってる理由は、移転に伴って検索エンジンの順位が下がったりとか、あとは 2005-09-15 の「mod_rewrite でリクエストに応じて gzip 圧縮ファイルを返す」などの効果のためだろう。

- sonic64.com の転送量の80%が RSS

興味深かったのが、転送量の内訳。infoseek ではこういう統計は提供されなかったし、httpd の生のアクセスログも提供されなかったので調べられなかったけど、今は生ログがもらえるので解析できた。

解析の結果、転送量のほとんどが http://sonic64.com/cl-full.xml に集中してることがわかった。60GB の転送量のうち、50816191KB、すなわち 50GB 程度がこの RSS の転送のために使われていた。cl-full.xml は「すべての記事全文を含む RSS」なので、サイズが大きいのは仕方がないが、それが sonic64.com の転送量の約80%を占めているとは、ちょっと意外だった。20%80%のパレートの法則を超えるような状態だ。

ちなみに、トップページ http://sonic64.com/ の月間転送量は 471425KB で、471MB。全体に占める割合はたったの 0.74%。まあ、こんなものでしょ。

月間60GBという転送量は、私の見積もりの範囲内なのでまったく問題ない。必要ならどんどんアクセスしてほしい。全体の転送量の80%が RSS というのはちょっと意外だったのだけど。infoseek からの移転先としてさくらインターネットを選んだ理由の一つは、転送量制限の値が高めで余裕があるからだ。

- HTTP リクエストヘッダ Accept-Encoding: gzip をちゃんと送ってる?

気になるのは、http://sonic64.com/cl-full.xml へアクセスするときに、HTTP リクエストヘッダ Accept-Encoding: gzip を送ってないクライアントが多いんじゃないかということ。

cl-full.xml は今日現在 4MB 弱のサイズがあるが、Accept-Encoding: gzip をつけて送れば900KB くらいに圧縮されたデータがサーバから返される。そのために 2005-09-15 の「mod_rewrite でリクエストに応じて gzip 圧縮ファイルを返す」などの仕組みを取り入れたんだけど、それが使われてなかったとしたら残念だ。無駄は嫌いなんだ。無駄、無駄、と。昨日のアクセスログを grep して調べてみる。

grep 'GET /cl-full.xml' ~/log/access_log_`date +%Y%m%d` |grep ' 200 '

上記のようにして 200 OK で完結したリクエストのログをざーっと眺めてみる。うん、以下の Mozilla Thunderbird は圧縮された cl-full.xml を取ってきてるね。返された cl-full.xml のサイズが 942606 バイトになってる。

"GET /cl-full.xml HTTP/1.1" 200 942606 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6"

一方、 Accept-Encoding: gzip をリクエストにつけていないため、圧縮してないデータを返されたクライアントも結構あった。とくに、ロボットや Web 型 RSS リーダーのクローラーにこの傾向が強いように感じる。

"GET /cl-full.xml HTTP/1.1" 200 4147427 "-" "Mozilla/4.0 (compatible; Google Desktop)"

以下、UserAgent 名だけ列挙。

InfoSeek RssReader/0.1"
FEEDBRINGER/0.1 (http://feedbringer.net/; 10 subscribers)"
Google Desktop
blogWatcher_crawler/0.2
Accelatech RSSCrawler/0.4
HepCat: http://www.witha.jp/
Hatena RSS/0.2 (http://r.hatena.ne.jp; 7 subscribers)
cococ/1.04
gooRSSreader2/2.0-build 20050818 (based on glucose)
Headline-Reader [t] (http://www.infomaker.jp/)

Bloglines はちゃんと Accept-Encoding: gzip をつけてリクエストしてる。さすがだね。

- Accept-Encoding: gzip なしのリクエストは mod_rewrite でリダイレクト

今のところ転送量にはまだ余裕がある。Accept-Encoding: gzip なしのリクエストを、圧縮しなきゃダメと 403 Forbidden で追い返したり、問答無用で圧縮したファイルを返すようなことはしたくない。でも、今時の HTTP クライアントなら Accept-Encoding: gzip くらい送ってきて欲しい。一般的なクライアント型 RSS リーダーだと、ファイアウォールソフトや proxy によって Accept-Encoding: gzip を削除されてしまうことがあるようだけど、ロボット系はそんなこともないだろうしなあ。

そうだ。Accept-Encoding: gzip を送ってきてないクライアントは、HTTP 302 Moved Temporarily で RSS 広告社の Trend Match の RSS http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0002 にリダイレクトするようにしよう。Trend Match から返される RSS は gzip 圧縮がかかってないから、問答無用で圧縮したファイルを返すよりもずっといい。

2005-10-12 の「RSS広告社の広告プログラム Trend Match に参加」で書いたように、http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0002 にアクセすると、Internal Server Error になってしまっていた。その後、2005-10-26 の「RSS広告社の Trend Match の RSS サイズ制限が緩和された?」で、エラーにならずにアクセスできるようになったのを確認した。正式対応のアナウンスはまだ無いが、いまのところ問題がない。そのうち cl-full.xml への全リクエストをリダイレクトしようかと思っていた。でもやっぱりいきなり全リクエストをリダイレクトするのは不安なので、まず一部だけでテストしたいところ。Accept-Encoding: gzip を送ってきてないリクエストにそのテスターになってもらうことにしよう。

さっそく mod_rewrite の RewriteRule を書こう。

RewriteCond %{REQUEST_URI} cl-full\.xml(\.gz)?$
RewriteCond %{HTTP:Accept-Encoding} !gzip
RewriteRule .+ http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0002 [L,R]

できた。これを .htaccess に設定して、Firefox と LiveHttpHeaders の HTTP リクエストリプレイ機能で、Accept-Encoding: gzip があるリクエストと、ないリクエストの両方でテスト。よし、OK だ。これで全員が幸せになれるね。Win-Win-Win だ。

2005-10-12 (Wed)

* RSS広告社の広告プログラム Trend Match に参加

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [sonic64.com] [RSS]

RSS広告社の広告プログラム Trend Match に参加した。

RSS広告社
https://www.rssad.jp/mp/

- RSS広告社の RSS 広告の仕組み

RSS広告社にアカウントを申し込み、サイトの審査に通過すると、自分の RSS を登録することができる。登録すると広告の入った RSS の URL を発行してもらえるので、それを自分のページの RSS として使うという流れ。

RSS は blog や CMS (Content Management System) の普及のおかげで多くのサイトで配布されるようになった。しかし、RSS広告社のシステムの場合、RSS の URL を自由に変更したり、HTML テンプレートを柔軟に変更できる環境にない場合は、導入が難しいかもしれない。とくに、一般の無料 blog サービスの場合、広告入りの RSS を広報するには、ほぼ不可能だと思う。システム側のサポートが不可欠だ。

- RSS広告社への申し込み

私のサイトくらいの規模だと収益が上がるかどうかは疑問だが、とりえあえずやってみることにする。レンタルサーバとドメインを維持する費用の足しになればいいな。

RSS広告社の個人向けページ https://www.rssad.jp/mp/ からアカウントを申し込む。審査は非常に迅速で、私の場合は一日くらいで審査通過の連絡が届いた。その後管理画面で RSS を登録して、広告入り RSS の URL を発行してもらう。私の場合、http://sonic64.com/cl.xml の広告入り URL として http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 を割り当てられた。

- 広告の入った RSS へのリダイレクト

あとは、http://sonic64.com/cl.xml ではなく、広告の入った URL である http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 にアクセスしてもらうようにするだけだ。2005-09-12 の「Landscape - エンジニアのメモは sonic64.com に移転しました」では、サーバの管理権が全くないので HTTP のリダイレクトを使えなかった。そのせいで URL の変更には多大な手間がかかってしまった。しかし、今は管理権付きのサービスを利用しているので、リダイレクトなどは自由に使える。Bloglines などの RSS リーダーで購読しているユーザーに手間をかけさせることがなくなり、非常に喜ばしい。

リダイレクトするための mod_rewrite の RewriteRule を書いた。

RewriteRule cl\.xml(\.gz)?$ http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 [R,L]

あんまり凝ったことはせずに、cl.xml または cl.xml.gz にアクセスされたら、http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 に HTTP 302 Moved Temporarily でリダイレクトしているだけ。ちなみに、cl.xml.gz は 2005-09-15 の「mod_rewrite でリクエストに応じて gzip 圧縮ファイルを返す」で設定した gzip 圧縮を施したファイル。cl.xml と中身は同じ。

これで良し。・・・と思ったけど、この程度なら mod_rewrite なんか使わなくても Redirect や RedirectMatch で十分だ。なんでわざわざ mod_rewrite を使おうとしたんだろう?

RedirectMatch cl\.xml(\.gz)?$ http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003

よしよし、これでいいね。あとは RSS広告社のクローラーが RSS を取りに来てくれれば OK。・・・と思ったけど、上記のリダイレクトには間違いがある。上記のルールだけだと RSSad のクローラーが最新の RSS を取りに来ても、必ず http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 にリダイレクトされてしまう。

これじゃいつまで経っても RSS が更新されない。何らかの方法でRSS広告社からのアクセスを判別して、RSS広告社からのアクセスだったときのみ最新の RSS を返し、それ以外のアクセスは http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0003 にリダイレクトする必要がある。

RSS広告社からのアクセスをどうやって判別しよう? UserAgent も IP アドレスもわからないんだよな。仕方がない、別の http://sonic64.com/cl.xml とは別の URL で RSS を置いて、それを RSS広告社に登録しよう。で、http://sonic64.com/cl.xml は常に 302 Moved Temporarily を返してリダイレクトするようにしよう。サーバ上で cl.xml にシンボリックリンクを張れば簡単に実現できるね。

- 過去の全記事の全文を収録した RSS にアクセスすると Internal Server Error

当サイト Landscape は過去の全記事の全文を収録した RSS http://sonic64.com/cl-full.xml も配布している。これもRSS広告社に登録しておこう。

登録し、割り当てられた URL http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0002 にテストのためにアクセスすると HTTP 500 Internal Server Error となってしまった。Tomcat から The server encountered an internal error () that prevented it from fulfilling this request. というエラーメッセージが出力されている。あ、RSS広告社のシステムは Java なんだね。

過去の全記事の全文を収録した RSS http://sonic64.com/cl-full.xml はサイズが 4MB 弱と大きめなので、それが原因かな。それとも、過去の記事の中に存在する半角カナや機種依存文字が悪さをしてるのかな? 私が推測しても仕方がないので、サポートに質問メールを送ることにする。

株式会社RSS広告社サポート担当者様

Trend Match ユーザーの斎藤と申します。
お世話になっております。

広告導入をの手続きをおこない、RSS の URL を割り当てられましたが、
アクセスすると 500 Internal Server Error になってしまいます。

URL は http://rss.rssad.jp/rss/qArzgZHGLg5Z/rss_0002 で、
私が作成している RSS は http://sonic64.com/cl-full.xml です。
RSS のサイズが大きいことが原因でしょうか?

HTTTP トランザクションの内容を付記します。

GET /rss/qArzgZHGLg5Z/rss_0002 HTTP/1.1
Host: rss.rssad.jp
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.12)
Gecko/20050919 Firefox/1.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 500 Internal Server Error
Date: Tue, 11 Oct 2005 22:43:25 GMT
Server: Apache/2.0.52 (CentOS)
Content-Length: 1023
Connection: close
Content-Type: text/html;charset=utf-8

以上、よろしくお願いいたします。

上記メールをサポートに送信した。あ、よく見ると HTTP が HTTTP になってたり、誤字があったりするな。恥ずかしい。あわただしい時間帯に送信したメールなので、読み返さなかったのが災いしたなあ。しかも、今 FAQ のページを見ていたら、質問用のテンプレートが用意されてるじゃん。完全に無視して質問メールを投げてしまった。エンジニアとして恥ずかしい。

よくある質問
https://www.rssad.jp/mp/faq.html#f41

41.メールで問合せをしたいのですが・・・

FAQをご覧頂いた上で、それでもおわかりにならない場合のみ、以下に注意してメールをお送り下さい。

(1)アカウント取得前・取得後で、お問い合わせ先メールアドレスが異なります。

●アカウント申請前のご質問(ご登録に関するご質問・審査報告の遅延など)
問い合わせ先：rss-support@rssad.jp

●アカウント取得後のご質問(広告挿入の手順・お支払い状況・登録内容/銀行口座の変更・退会処理など)
問い合わせ先：rss-adhelp@rssad.jp

(2)お問い合わせの際、お客様のご質問に迅速に対応させて頂くため、本文に以下のフォーマットを記入してお送り下さい。

1.【氏名】
2.【サイトURL】
3.【E-mail】(アカウントをお持ちの方は登録時のE-mail)
4.【お使いのブログサービス会社】Livedoor Blog、ココログ、Excite Blog　等
5.【利用ブラウザ】IE6.0、firefox、Netscape、Sleipneir等
6.【質問ジャンル】登録申請・審査報告の遅延・広告挿入・レポート・お支払い・支払い状況・登録内容/銀行口座の変更・退会・その他　(うち一つをお選び下さい)
7.【詳しい質問内容】

テンプレートを完全に無視した質問メールだったが、ちゃんと返事をくれた。調査してくれるとのこと。回答待ちだな。

斎藤様

お問い合わせありがとうございます。
「Trend Match」カスタマーサポートセンターと申します。

現在、本件に関しては、技術部門で原因を追求中です。
斎藤様のご指摘のとおり、RSSのサイズが大きいことが原因である
可能性が高いと思われます。

早急に調査し、ご連絡申し上げますので、
ご迷惑をおかけ致しますが、今しばらくお待ちください。

何卒よろしくお願いいたします。

2005-09-18 (Sun)

* .htaccess などを使えないレンタルホームページスペースでのサイト移転告知

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [sonic64.com]

2005-09-12 の移転告知について指摘をいただいた。

[2758]http://sonic64.hp.infoseek.co.jp/2005-09-12.html#2005-09-12- ...
http://tokuhirom.dnsalias.org/~tokuhirom/inamode4/2758.html

http://sonic64.hp.infoseek.co.jp/2005-09-12.html#2005-09-12-1

移転元サイトのサーバ設定権限がないため、HTTP Status 301 Moved Permanently を使用したリダイレクトができません。

http://isweb.www.infoseek.co.jp/Icont?pg=iw_spec.html
をみるとinfoseekってCGI使えるんだから自力でnph-cgiでヘッダーを出力すればいいんじゃないの？
でもHandlerが変えられないと難しいか。

nph-cgi ってなんだっけ? あ、HTTP ステータスも含めて生成するタイプの CGI のことか。 HTTP ステータスコードを操作したいときは CGI 中で Status: 304 を出力するなどしてたので、nph って使ったことない。そこまでパフォーマンスを追求したチューニングをする機会がなかったから。

でも、nph-cgi を使ったとしても、指摘の通りハンドラの問題がある。結局、infoseek では CGI は cgi-bin 以外では動かないし、拡張子も .cgi じゃないとダメ。そして、.htaccess が一切使えないからハンドラも変えられない。八方ふさがりだよなあ。

とにかくやってみるか。
infoseek でも nph で始まるファイル名にすれば、確かに nph-cgi として動かすことは可能。しかし、cgi-bin ディレクトリに配置しなければならない。それ以外のディレクトリにスクリプトを置いても 403 Forbidden になる。というわけで、301 Moved Permanently を出力することはできなかった。残念だ。

- 無料レンタルホームページスペースと移転告知

結局、無料なんだから出来ることが少ないのは仕方ない。無料ホームページスペースなどは使わずに、最初から独自ドメインを取っていれば良かったんだけど、そこまでする気はなかったんだよなあ。趣味というかあくまでもメモなんだから、そんなことしなくても無料ホームページスペースで十分だと思ってた。

今は無料レンタル Blog がたくさんあるけど、いざ移転というときに、私と同じような状態になってる人は結構いるんだろうなあ。そういうとき、みんなどうしてるんだろう? 結局、無料レンタルホームページスペースなどでできることは以下くらいだろうか。

旧サイトのできるだけ多くのページに、新サイトへの移転告知を掲載する。
移転に気づいてもらうことが大切。そうしないといつまで経っても新サイトに人が来ない。移転に気づかずに旧サイトばかり見ている人には「更新停止?」などと誤解されるかも。

Meta 要素の Refresh を使って自動的に新サイトに飛ばす。

<meta http-equiv="refresh" content="5; url=http://sonic64.com/">

よくある、「5秒後に自動で新サイトにジャンプします」ってやつ。
どの記事ページにアクセスされても画一的に新サイトのトップページに飛ばすだけなら簡単。しかし、記事を追跡しつつ新サイトに飛ばそうとするとちょっと大変。たとえば http://sonic64.hp.infoseek.co.jp/2005-09-12.html にアクセスされたら http://sonic64.com/2005-09-12.html に飛ばす、というのは、一つ一つ meta 要素を埋め込まなければならない。 Blog ツールや CMS (Content Management System) を使ってるサイトなら楽勝だが、そういう仕組みがない場合は手間がかかる。

JavaScript で飛ばす。
ツールや CMS が無く、meta 要素を埋め込むのが大変な場合は場合はこっちの方が簡単。
たとえば、sonic64.hp.infoseek.co.jp/YYYY-MM-DD.html を sonic64.com/YYYY-MM-DD.html に置換して location オブジェクトに代入するというスクリプトを書けばいい。

旧サイトへのサーチエンジンのロボット巡回を抑制する。
検索でヒットするのが旧サイトばっかりだと、新サイトに人が来ない。robots.txt や meta 要素でロボットの巡回とインデックスを抑制する。

あとは、旧 URL のままになってしまっている部分を極力減らしていくことが大切。
メールの署名とか、vCard、プログラムの著作権表示とか、名刺、IME の辞書に登録している URL などを全部新しい URL に変えること。一気にやろうとすると大変なので、気づいたところから少しずつやっていこう。あ、2004-10-21 の「mixi 用自画像を作成」作った画像に埋め込まれてる URL も変えなきゃ。

2005-09-12 (Mon)

* Landscape - エンジニアのメモは sonic64.com に移転しました

この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [sonic64.com]

Landscape - エンジニアのメモは、http://sonic64.com/ に移転しました。

- Landscape - エンジニアのメモ新 URL

Landscape - エンジニアのメモ
http://sonic64.com/

RSS の URL は以下の通りです。後述の「各種 RSS リーダー・アンテナ向け登録リンク」もご利用ください。

直近7日分の記事全文の RSS
http://sonic64.com/cl.xml

過去の全記事全文の RSS
http://sonic64.com/cl-full.xml

- 過去の記事について

過去の記事は http://sonic64.com/ に移転しました。すべて新 URL で閲覧できます。

- 旧 URL sonic64.hp.infoseek.co.jp について

Landsacpe - エンジニアのメモの旧 URL である sonic64.hp.infoseek.co.jp は、可能な限り過去記事の掲載を続け、リンク切れを防ぎます。

また、しばらくの間は http://sonic64.com/ の新規記事も http://sonic64.hp.infoseek.co.jp/ に掲載します。ただし、新規記事は http://sonic64.com/ に先に掲載し、数日以内に http://sonic64.hp.infoseek.co.jp/ にもミラーするという形で運用します。