2017年04月25日

さくらのレンタルサーバライトでContent-Encoding: gzipの無効化について

 このブログがさくらのブログであることからも明らかですが、さくらのレンタルサーバライトを利用して、いくつかのWebサービスを運用しております。
 何年も前に青空文庫形態素解析データ集というサイトを作っておりまして、このサイトもさくらのレンタルサーバ上にコンテンツを配置しております。

 その名の通り、青空文庫で公開されているデータを形態素解析した結果をzipやらgzipでダウンロードできるサイトなのですが、先日gzip圧縮されているファイルをダウンロードしたところ、拡張子はgzなのに、実際は解凍済みのファイルがダウンロードされるという事象が発生しました。

 一括ダウンロードのページでは、わざわざ解凍前と解凍後のサイズを明記しているというのに…

 オペミスか何かで解凍済みのファイルを拡張子をgzとして配置してしまったのかとも思いましたが、サーバに格納されているファイルを確認すると、ちゃんとgzip圧縮されたファイルが配置されていました。

 どうも、Content-Encodingのgzipが有効になっていて、圧縮転送がされているとブラウザ(Chrome)が判断して、自動的に解凍してしまっている模様です。

 はて、Content-Encodingのgzipとは、意図的に設定しないでも勝手につくものだったのかしら…ということも気になりますが、とりあえずはブラウザで解凍されないようにすることが先決ですので、方法を調べてみました。

 で、思ったより苦戦しましたが、とりあえず、.htaccessに以下を追記することで、Chromeでは解凍されずにダウンロードできるようになりました。



<FilesMatch "\.gz$">
  AddEncoding identity .gz
</FilesMatch>


 さて、以下は上記に至るまでの経過を示していきます。内容に不備があるようであれば、有識者の方は突っ込みをお願いいたします。

 そもそも、ブラウザがgzファイルを解凍してしまうのは、HTTPレスポンスヘッダのContent-Encodingにgzipが含まれているからではないかと推測し、Wiresharkでパケットを確認した結果、確かに「Content-Encoding: gzip」が含まれていました。

 ちなみに、他のサイトでgzファイルをダウンロードしても自動的に解凍されませんでした(レスポンスにContent-Encodingそのものがなかった)ので、やはりサーバの設定の問題のようです。


 で、ブラウザに解凍をさせたくない場合は、Content-Encodingヘッダそのものをつけないのが正しいようですので、初めはmod_headersを用いて以下のようにしてみましたが、どうにもContent-Encodingヘッダが削除されませんでした。

<FilesMatch "\.gz$">
  Header unset Content-Encoding
</FilesMatch>

 ETagヘッダで試してみると問題なく削除できましたので、機能が動作していないということはない筈なのですが…
 あまり自信のない推測ですが、Content-Encodingヘッダはレスポンスヘッダの末尾についておりますので、除去された後にもう一度付与されている…のでしょうか。(私の単なる勘違いだったら申し訳ないですが)

 次は、Content-Encodingを削除することは一旦あきらめて、内容を変更する方法で検討しました。
 AddEncodingで変更できることはわかったのですが、何の文字列に変更すべきかがわからない

 RFC2616を見る限りでは…以下のような記載がありますので、やはり、identityが一番近いように読めます。

identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header.


(長時間かけてググったわけではないですが、同じ事象で困っている人は見つけられませんでしたので、何か私が根本的な勘違いをしている気もしておりますが…)
posted by hahasoha at 23:04| Comment(0) | TrackBack(0) | その他

2017年03月12日

BVH WEB VIEWERを公開しました

BVH WEB VIEWERを公開しました。
http://motion.hahasoha.net/


 ひょんなことからVRに触れることになり、関連しそうな情報を色々と調べていたところ、カーネギーメロン大学が公開しているモーションデータをbvh形式に変換して公開しているサイトを見つけました。

 必要なツールをダウンロードしてbvhファイルを読み込めば、色々なモーションが見れてなかなか楽しいです。
 …が、もっと気軽に検索できて、パパッとモーションを閲覧できる方法がないか調べた結果、どうも適合するサイトはなさそうでしたので、冒頭のBVH WEB VIEWERを作成し、公開しました。

 作成したといっても、three.jsのサンプルコードも殆ど流用させてもらっていますし、手抜き感は否めませんが…
 パパッとモーションを検索して、ブラウザで動作を確認してそのままbvhファイルをダウンロードできるようにしましたので、使い勝手は悪くはないかと思います。(手元のスマホで表示をしたらiframeが荒ぶったため、とりあえずPC限定としていますが)

 ただ、実際に動きを見ても、何の動きなのかわからないのも多数ありますが…(Alaskan vacationって何なんでしょう…?)

 3Dコンテンツの作成は完全に門外漢なので、どれくらいの需要があるのか把握できておりませんが、bvhファイルはBlenderではそのまま使えるようですし、ドリームファクトリーのLiveAnimationで変換すればMMDでも使える模様です。

 2016年はVR元年と言われていますが、3D系の素材に対する需要・供給も増加していきそうですね。
posted by hahasoha at 16:31| Comment(0) | TrackBack(0) | その他

2016年02月13日

Raspberry PiのGPUアンダークロックと消費電力について

前日の記事に引き続き、今度はCPUに加えてGPUもアンダークロックした場合の消費電力について調査しました。

使用したモバイルバッテリや条件は以前の記事をご参照ください。

まず、/boot/config.txt に gpu_freq=100 と追記してPi Zeroを再起動しようとすると、ディスプレイが点滅を繰り返し、正常起動できませんでした。(公式サイトによると、デフォルトは250だそうです)
HDMIを接続して画面表示をしようとしていたので、もしかしたらHDMI接続をしなければ起動可能なのかもしれません。

で、このままだと起動できなくて困ってしまうわけですが、電源投入時にShiftキーを押下してリカバリモードに入れば、/boot/config.txt の内容を編集できるGUIが表示されます。

gpu_freqを100から150に変更したらHDMIを接続した状態での起動に成功しました。

前述の公式サイトに寄るとcore_freq, h264_freq, isp_freq,v3d_freqも一緒にセットしろと書かれているようですので、あわせて150に設定してみました。

結果としては、9時間36分間、起動し続けました。

これまでに確認したZeroの起動時間をまとめると以下のようになります。

 8時間30分 デフォルト状態
 8時間48分 arm_freq 100
 9時間36分 arm_freq 100、gpu系5種 150

繰り返しテストしたわけではありませんので信頼性は高くはありませんが、GPU系のアンダークロックは10%ほど消費電力を抑える効果が見込めそうですね。
タグ:Raspberry Pi
posted by hahasoha at 00:00| Comment(0) | Raspberry Pi