#author("2021-02-03T08:04:38+00:00","default:admin","admin") 開発者の敵(爆) *WebSocket [#q23762db] -[[「i-FILTER」 WebSocket通信には対応していますか:https://www.pa-solution.net/daj/bs/faq/detail.aspx?id=3697&a=102&isCrawler=1]] --「i-FILTER」は、WebSocket通信には非対応です。 --※現状、対応の予定はございません。 --該当通信は「i-FILTER」を経由させないようにしてください。 --[[「i-FILTER」特定のリクエストのみ「i-FILTER」を経由させない設定は可能ですか:https://www.pa-solution.net/daj/bs/faq/Detail.aspx?id=2835]] -[[サーバからクライアントに送信する技術 - WebSocketを中心に:https://qiita.com/yuba/items/00fc1892b296fb7b8de9]] --i-FILTERは上記のプロキシサーバの事情とは別の理由でWebSocketを止めてしまいます。 --フィルタリングポリシーに違反するからかと思いきやそうではなく、WebSocketのプロトコルを理解できずに手を出してこけているというもの。しかも2重にこけています。 ---サーバからのレスポンスヘッダのうち、Connection ヘッダを書き換えてしまいます。これでWebSocketの規格違反になり、大部分のWebSocketクライアントライブラリは接続失敗と判定します。 ---JavaScript以外のクライアントなら、クライアント側をごにょごにょして Connection ヘッダの規格違反を無視するようにできるでしょう。しかしそうしても、上りのメッセージがサーバに届きません。 ---ここの仕組みはまだ完全には解析できていませんが、おそらくi-FILTERが一問一答型の通信を想定しているため、上りメッセージもHTTPリクエストだと解釈し、ヘッダセクションだとして解析しようとバッファしてそのまま止まってしまっている、そんな動きに見えます。 --ソフトウェア側での対策はできず、i-FILTERの設定をいじってホスト名だかIPアドレスだかを基準に除外設定してもらうしかありません。 *ユーザー認証 [#f6c9827b] -[[「i-FILTER」 ユーザー認証に対応していないアプリケーションやアドオン通信が正常に動作しません:https://www.pa-solution.net/daj/bs/faq/Detail.aspx?id=2889&dispNodeId=]] *回避策 [#p6a9bdaa] **Windows [#zffee7ed] -環境変数 HTTP_PROXY, HTTPS_PROXY の設定 set http_proxy=http://[ユーザID]:[パスワード]@[ProxyのIPアドレス]:[Proxyのポート番号] set https_proxy=http://[ユーザID]:[パスワード]@[ProxyのIPアドレス]:[Proxyのポート番号] **Linux [#a72d73d8] -[[【Linux】Proxy設定:https://kaede.jp/2020/04/22225145/]] -[[[Linux] wgetをプロキシ経由で実行する方法:https://qiita.com/nutti/items/4ed09d3d61ccad49069b]] -.bashrcに以下を記載 export http_proxy=http[s]://[ユーザID]:[パスワード]@[ProxyのIPアドレス]:[Proxyのポート番号] export https_proxy=http[s]://[ユーザID]:[パスワード]@[ProxyのIPアドレス]:[Proxyのポート番号] export ftp_proxy=http[s]://[ユーザID]:[パスワード]@[ProxyのIPアドレス]:[Proxyのポート番号] export no_proxy="127.0.0.1,localhost" -wgetを使う場合は、.wgetrcを以下のように記載 http_proxy=http://[ProxyのIPアドレス]:[Proxyのポート番号] https_proxy=https://[ProxyのIPアドレス]:[Proxyのポート番号] proxy_user=[ユーザID] proxy_password=[パスワード]