カテゴリーアーカイブ 未分類

著者:takahashi

Internet Explorer でGETが予期しない動作をする

高橋です。

現在開発中のシステムで、サーバー側のプログラム(PHP)へGETで値を渡す処理を書いていたのですが、InternetExplorerで実行すると何故か正常に値が渡せないという現象が発生していました。
他のブラウザでは問題なく動作するので、プログラム側の不具合ではないようなのですが、IEでアクセスする方も少なくないので、解決策を調べてみました。

1.URLが約2083文字を超えるとIEで扱えない

IE11で使用可能なURL文字数が2083文字しかない件 – 文系プログラマによるTIPSブログ
によると、InternetExplorerでは、URLの最長文字列長は2083文字までらしく、それ以上は認識できないとのこと。
GETでパラメーターを複数入れると、URLがどんどん長くなっていってしまうため、あまり渡す値が多い場合は注意が必要かもしれません。

2.Eで2番目以降のGETパラメータが実体参照になり値が取得できない

少し古い記事ですが
IEで2番目以降のGETパラメータが実体参照になり値が取得できないバグ – DevAchieve

によると、GETで渡すパラメーターの1個目と2個目の間にいれる&記号によって、2個目以降の値が実体参照として処理されてしまうことがあるとのこと。

他にもGETで渡したパラメーターの値が文字化けしてしまうケースなど、IEでは予期しない動作をしてしまうことがあるようです。

いろいろ考えた結果、デバッグの際はIE以外のブラウザでURL直打ちで値を渡せるGETを使い、うまく動くことを確認したらPOSTに切り替える方法で運用することにしました。

大抵のフレームワークではメソッドの判定を簡単に行うことができるように関数が用意されています。
例えばfuelでは

if( Input::method() == 'POST' ) {
   //POSTされた場合の処理
}
if( Input::method() == 'GET' ){
  //GETされた場合の処理
}

のように、メソッドに応じて処理を書き分けることもできます。
中の処理を同じものにしておけば、クライアント側の使用するメソッドを切り替えるだけで済むので便利です。

今後はIEを考慮しないWebアプリも増えていきそうですが、現時点ではIEがまだ現役で使われているところも多いかと思います。
他のブラウザとIEの互換性を確保するためには、いろいろ工夫していく必要がありそうです。

著者:takahashi

位置情報配信プロトコルのNTRIPをNginxでリバースプロキシする方法

高橋です。

ご存知の方もいらっしゃるかもしれませんが、静岡大学浜松キャンパスに設置された高精度のGNSSアンテナを用いた測位情報を配信するシステム(hamamtsu-gnss.org)が整い、ついに浜松市内でRTK(リアルタイムキネマティック)ができる環境が整いました。

詳しくは
https://hamamatsu-gnss.org/
をご覧いただけましたら幸いです。

ざっくり説明するとRTKを行う際、実際に自分の位置を計測する”移動局(ローバー)”と、厳密な位置情報が既にわかっている場所に置かれた”固定局(ベース)”の2つが必要となってきます。したがって移動局は何らかの方法で固定局の情報を受信し続ける必要があるのですが、その方法として、”インターネット”経由で受信を行う方法があります。
今回開設されたhamamatsu-gnss.org局もインターネット経由で位置情報を配信するタイプの固定局で、配信プロトコルとして”NTRIP”と呼ばれるものを利用しています。

さて、そのhamamatsu-gnss.orgを開設する際に、”大学などでも受信できるように80番ポートで通信できるようにしてほしい。”という話がありました。
大学などの教育機関では、ネットワークに制限を設けているところが多く、80(http)、443(https)あたりの必要最低限のポートしか開けていないところも多くあります。
しかし、hamamatsu-gnss.orgのホームページも同様に80番ポートを使用するので、このままでは両立ができません。

最近はNode.jsやRuby on Railsなどが出回ってきて、同ホストに複数のWebサーバが立つことも少なくはなくなってきているので、今回のように一つのポートを取り合ってしまうような事態も往々にしてあります。こういう場合は”リバースプロキシ”という仕組みを用いることで一つのポートを複数のサーバープログラムで共有することができます。

今回も、まず思いついたのはこの方法だったのですが、今回共有させたいのはNTRIPという得体のしれないプロトコル。
いろいろ調べてみてもNTRIPとHTTPを同時にプロキシできるソフトやプログラムは見つけられませんでした。

どうしよかと困っていたところ、あることが判明。

http://gpspp.sakura.ne.jp/diary200703.htm
こちらのサイトで解説されているようにNTRIPはなんとHTTPベースのプロトコルでした…！（プロジェクトを共同で進めている木谷先生に教えていただきました。）

一応実験としてブラウザからNtip配信のポートに直繋ぎしてみたら、ちゃんとレスポンスが返ってきました。

telnetでも確認しましたが、ちゃんと応答が返ってきます。

しかし、NTRIPがHTTPのデータとして扱うことができるというのであれば話は早い。
上にあげたのと同様にリバースプロキシしてやれば共存させられます。

ということで早速設定。
リバースプロキシには非常に柔軟な設定ができる有能なNginxを使います。
（NginxはWebサーバーでありながらHTTP以外にもimapやpop、さらにはtcp（ドメインベースは不可）のプロキシができたりする、いい意味でかなり変態なソフトです。）

早速設定していきます。
一部省略してますが、以下のような設定にしました。

バーチャルホスト(https)

server {

  listen 443 default_server; #443番にアクセスされた時のデフォルトのバーチャルホストに設定

  ssl on;
  ssl_certificate /path/to/ssl.pem; #SSL証明書のパス
  ssl_certificate_key /path/to/sslkey.pem; #SSL証明書の秘密鍵のパス

  client_max_body_size 1g;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # クライアントの IP アドレス
  proxy_set_header X-Forwarded-Host $host; # オリジナルのホスト名クライアントが Host リクエストヘッダで渡す。
  proxy_set_header X-Forwarded-Server $host; # プロキシサーバのホスト名
  proxy_set_header X-Real-IP $remote_addr;
  location / {
    proxy_pass https://localhost:8081; #プロキシの向き先の設定(https)
  }
}

バーチャルホスト(NTRIP)

server {
    listen 80 default_server; #80番にアクセスされた時のデフォルトのバーチャルホストに設定
    server_name .ntrip.hamamatsu-gnss.org;

        client_max_body_size 1g;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Connection "";

　　　　 #伝送を効率化するチューニング
        keepalive_timeout 0; #キープアライブ無効化
        tcp_nodelay on; #パケットを極力まとめて送付するNagleアルゴリズムを無効化
        tcp_nopush off; #関係なさそうだが一応設定
        proxy_buffering off; #バッファリング無効化(重要)
        #効率化設定ここまで
        location / {
                proxy_pass http://localhost:2101; #プロキシの向け先をNTRIPサーバーに設定
        }
}

当環境では今後を考えてhamamatsu-gnss.org:80へのアクセスはhamamatsu-gnss.org:443へリダイレクトさせてますが、80番でWebページを待ち受けることも可能です。

回線の輻輳を防ぐためにある程度データをまとめて送付しようとする機能がNginxにありますが、ストリーミングの場合は遅延につながってしまいます。
チューニングはこの設定の無効化が主となっています。

HTTPに準拠している以上はhostヘッダーにアクセス時のホスト名を含めるルールになっているのですが、一部のNTRIPクライアントでアクセスしたときは何故か判定がうまく行かずにデフォルトのバーチャルホストへつながってしまうことがありました。
Webページの方は最近のブラウザであればデフォルトでなくても問題なくつながるので、80番ポートのデフォルトをNTRIP側に設定してあります。

これで無事NTRIPが一般配信できるようになりました。

今後、RTK-GNSS向けの位置情報の配信サービスを構築予定…という方は是非参考にしていただけましたら幸いです。

hamamatsu-gnss.orgはGPS以外にも複数の測位衛星から受信したデータを配信していて、RTK-GPSよりも高い精度で測位ができます。
全国には他には殆どない設備ですので、是非ご活用いただけましたら嬉しいです。

———————————————————-

位置情報の精度、センチ単位に　静大准教授ら研究 – @S
http://www.at-s.com/news/article/education/college/367429.html

※この記事は、以前私が書いた記事の本文を一部修正したものです

著者:takahashi

【コンピューターって何？】 Appleがアピールする”PCのない未来”とは

初めまして。シーポイントラボの高橋です。
これからIT技術やその周辺の話題について、皆さんにご紹介できればと考えています。

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

さて先日、気になる記事を発見しました。

Photo by カミアプ

「コンピュータって何？」Appleが目指すiPadの未来はPC以上の存在か – カミアプ

iPad Proは文字を書ける。絵も描ける。写真も撮れる。コミックも読める。誰かとコミュニケーションも取れる。
ここまでできて、果たしてこの先の未来にコンピューターは必要なのか？

そんなAppleの主張を感じることができます。

身の回りにある電子機器は、時代が進むごとに形や担う機能が変わってきました。

黒電話からプッシュフォンのような、ただ声のやり取りができるだけだったデバイスから、ガラケー、そしてガラケーからスマートフォン。
そしてつい先日、音声のみで操作ができるデバイス、Google Home と Amazon Echo、Line Clova が発表され、操作に画面すら必要としないデバイスも出てきました。

PCもまた、徐々にデスクトップPCからどこにでも持ち運べるモバイルPCへと、需要がシフトして行っているように思えます。

両社のその行き着く先は、確かに同じところではないでしょうか？

僕は開発者なので、正直タブレットより大きな画面としっかりとしたキーボードのあるPCの方が使いやすいですし、個人的にタブレットで長文を書いたり…はあまりしたくないなーというのが正直なところです。
また、iOSよりも現在のデスクトップPC用のOSの方が機能面でも優れているので、まだ取って代われるレベルとまでは言えないのかな、と考えています。

ただ、一方でもしもう少しこれらのデバイスが進化したら…今のPCと同等か、それ以上の使い勝手や機能をそなえたら、もしかすると”PCのない未来”は実際にやってくるのかもしれませんね。

もしかすると動画のように、「コンピューター（パソコン）って何？」と言う子供たちも出てくるかもしれません。

皆さんはどう考えますか？