NGINXやApache(おそらくSQUIDでも)あたりでReverse Proxy(まぁ、Load Balancer的に使う設定)をしようとした場合に、中継段となるhttpdでHeaderを追加したいことはしばしばある。 こういう場合に、X-xxx-xxxのようなHeaderを追加することがしばしばある。

しかし、この手法は、一般的によく利用されている慣習であって、HTTP Protocol的に規定されているものではなかった。そして、この慣習は2012年6月に非推奨となった。

なぜそうなったかに関してはRFC6648を参照のこと。まぁ、要するに「非標準のフィールドが標準になったときに発生した不便さのため」ということになると思う。

んで、どうすりゃいいかということなのだが、要するに「使われていない」かつ意味がわかりやすいものを使えということらしい。

でも、それはそれで困るよなぁ…….

仕方がないから、被りそうもない文字列を入れるしかないか。

非常に個人的な意見なので、気に入らない人は華麗にスルーしてください。

http://itpro.nikkeibp.co.jp/atcl/column/14/549762/062900154/?n_cid=nbpitp_fbed&rt=nocnt&ST=spleafの記事についておもうことを少し。

• googleが検索市場で独占的な地位にいる
  • 代替が事実上存在しない(百度？bing? yahoo?)以上、独占状態になるのは当然。
  • これだけの長きにわたって、「無料で高精度」の検索エンジンを提供しているのだから、googleがすごいのだとしか言いようもない。
  • 対抗が現れるまではどうしようもないというのが実情だろう

• スポンサー広告を優先して、公平な市場競争を阻害した
  • タダで受け取っている情報にある種のバイアスがかかるのは当然。
  • バイアスは小さい方が望ましいが、googleはボランティアではない。
  • バイアスがかかることが嫌なら検索エンジンを変えればいい。ないなら作るしかない。(死屍累々の道だけど)

個人的には、googleが正しいとは思わない(むしろできるなら使いたくない)。しかし、この件に関して言えば、「ヨーロッパすらこの程度か。日本の民間人と変わらないレベルだ」と思ってしまう。世界的に「情報と安全はタダ」の方向に思考が向かっているとしか思えない。本当なら、利用する側がすべき選択や判断を提供者側に押し付けて、自らは被害を受けた、的なワガママに見えてしまう。

いっそ、googleは、「バイアスをかけない検索結果の提供」を始めればいいんじゃないかと。「有料」で。そうすれば、情報の対価と、企業広告・スポンサードの意味がわかるんじゃないか？とおもうのです。

わかるかなぁ(松鶴家千とせ風)

山賀さんの記事より。

要するに、

• 多くのユーザーが、脆弱性を抱えているadobe flashを利用している
• 調査範囲内では、古いプレーヤーの利用率が、前年の調査より上がっている
• flash playerの利用率自体は減少傾向にある
• duo securityは、chromeの利用を推奨している。セキュリティ系の企業が名指しで実装を推奨するのは珍しい

といった内容です。

記事中に記載されていませんでしたが、Duo security (最初avastと書きましたが、思い込みでの勘違いでした。訂正します) がchromeを推すのは、恐らく、

1. chrome自身にflash playerが内蔵されている
2. chromeは更新が早く、常に最新のflash playerに対応している
3. 調査結果から、割合chromeユーザーは更新頻度が高いと見られる

からでしょう。推すことに対する是非は人によるでしょうが、例えばavastは昔からchrome推しなので、まぁそんなものかと。 まだ、著者の山賀さん曰く

「あまりの調査結果に「やむにやまれず」という思いはちょっと感じられます^^」

とありましたが、僕もそう思います。

個人的にはflashはもう滅びて欲しいけど、使うなら常に最新の物を使いたいものですね。

困るのは、子供付けのページの動画がflashが多いことだな。これは、なんとかならないものかと思います。

本サイトを含め、個人的に管理しているサイトがそこそこあるわけだが、昨今の様々な要請からSSL化を進めることにした。 （そういうわけでLet's Encryptと格闘していたのだが）

その結果、WordPressとRedmine系を除いて、概ねLet's Encryptの証明書を利用したSSL化が一通り区切りがついた。

まぁ、証明書が入手できさえすれば、SSL化は簡単ではあるけど。

server {
  listen      xxx.xxx.xxx.xxx:80;
  server_name www.seirios.org;
  return      301 https://$host$request_uri;
}

server {
  listen      xxx.xxx.xxx.xxx:443 ssl;
  server_name www.seirios.org;
  ssl         on;
  ...
}

結構重要なこととして、コンテンツ側に記載されているLink等のうち、自らを示しているURLを一通り確認すること。 これをしないと、結局一部SSL化されないURLが残るので、面倒なことになりかねない。

大変にハマったのでメモ書き。今日はもういいや。

shell scriptにおいて、ファイルから1行ずつ読み込んで処理をするような場合、以下のようにかける。

while read line; do
  echo ${line}
done < file

ところが、この手を使ってsshを実行すると、なぜか最初の行しか実行されない

while read line; do
  ssh xxx.xxx.xxx.xxx ${line}	# XXX 期待通りに動かない
done < file

原因はsshコマンド実行に伴う標準入力の切替と考えられる。 sshコマンドを実行すると、ローカルホストのstdinからの入力を終了し、sshで指定したリモートホストのstdinからの入力受付を開始する。 従って、ローカルホストのファイルの読込みを終了させた上でsshコマンドを実行し、再びreadコマンドを実行しようとしていると考えられる。もちろん、この時点で既にファイルがcloseされている為、whileが終了してしまう。

対策は、sshに-nオプションをつけること。これよって、sshコマンドのstdin切り替えを禁止することが出来る。

この原因がちっともわからず、数時間を無駄にしてしまった。

while read line; do
  ssh -n xxx.xxx.xxx.xxx ${line}	# これで/dev/nullがsshのstdinにつながる
done < file

このほかに、for文で for line in `cat file` で代用する手も考えられるが、これは、行にスペースがある場合、$lineに代入される値が１行まるごとではなく、スペースまでの部分になるので、ここにも明確な罠があると考えられる。これを回避するにはIFSを変えれば良いのだから、

IFS=$'\n'				# 区切り文字を" "から"\n"に変える
for line in `cat file`; do		# while readの代わりにcatで読み込ませる
  ssh -n xxx.xxx.xxx.xxx ${line}
done

あと、whileはちょっと特殊な制御文で、場合によってはwhile内で変数設定しているはずなのにloopをでてくると変数が空のようなことが起こる。 これは、Whileと他のコマンドを組み合わせた場合、組み合わせ方次第で処理がsubshellがわで処理されてしまう事が原因である。 shellでpipelineを用いて実行した処理は、subshellで処理される。while loopの内部でpipelineを利用すると、whileブロック全体がsubshellで処理されるため、whileブロックの内部と外部で変数の共有が出来ない。 このような場合、whileに対して出力をredirectしてやることで解決できる。

while read line; do
  OUT=`echo ${line} | sed 's/test/test2'`
done < $1
echo ${OUT}

なお、/bin/shの引数に -v や -x をつけると、デバッグに大変に役立つ