アカウント名:
パスワード:
こんなことまでできてしまうってのは、不安でもあったり。
今までだってGoogle Mapsぐらいのことはできたんだし
WebSocketって、FirewallやProxyを越えられるんですかね？？
なんか、企業ネットワークにとってはあまり嬉しくないもののような気がして、矛と盾のような気がするんだけど、どうなんでしょう？？
80番なら越えられるでしょうね。金盾みたいな本格的なファイアーウォールでヘッダまでチェックすると弾けるかもしれませんけど、しばらくは判定のための経験を蓄積する必要があるんじゃないでしょうか。
というか、企業側からすれば、ブラウザの設定でwebsocketを切ればいいだけの気がします。もちろん、それで動かなくなるサイトもいくらか出てくるでしょうが、ファイアーウォールで禁止した際にも当然そうなるでしょうから、どのみち変わらない気がします。
「Web」ってついてるのが既存のhttpスキームのパスを通過させるというニュアンスですので、httpで閲覧してるならほぼ通るはずかと。
> 矛と盾のような気が...httpの1コネクション上で非同期（理想的にはリアルタイム）通信をするので、いままでできなかったことができる！系の進化ですが、個人的な比喩的には、ふつーの矛の先端に最強の盾をつけてぶんなぐったらなにこれ超最強じゃん！みたいな奇異感のある実装と思ってます。
現実、いままで複数コネクションだったら発生したオーバーヘッドがなくなるじゃん？に対して、でもコネクション管理（特に1コネクションあたりの伝送量の短期的見積もり）がよりめんどくなるじゃん？のトレードオフだと、個人的には思ってます。
ふつーの矛の先端に最強の盾をつけてぶんなぐったらなにこれ超最強じゃん！
人はそれを円匙とい…わないか
#2125897のACですが不安になったので調べてみました（あとだしジャンケンで失礼しますm(_ _)m）proxy超えは以下のPOSTにもある通りRFC的にHTTP CONNECTがSHOULDだそうです。ですので勘違いさすというより対応してよねー感のようですた。
http://onmessage.ws/wordpress/?p=214 [onmessage.ws] > ここを見て頂くと分かりますが、proxyを経由する必要がある場合には、>> CONNECT example.com:80 HTTP/1.1> Host: example.com>>
同じACですが訂正です。「RFC的に...」は間違いで「ドラフト（draft-ietf-hybi-thewebsocketprotocol-07）的に」が正しいです。
# RFC2616/2817の方に頭がひっぱられちゃった:3# parosみたいにconnectでも中身みてやるぜーだと問題がおこりそう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
逆に怖い (スコア:0)
こんなことまでできてしまうってのは、不安でもあったり。
Re: (スコア:0)
今までだってGoogle Mapsぐらいのことはできたんだし
Re: (スコア:0)
WebSocketって、FirewallやProxyを越えられるんですかね？？
なんか、企業ネットワークにとってはあまり嬉しくないもののような気がして、
矛と盾のような気がするんだけど、どうなんでしょう？？
Re:逆に怖い (スコア:1)
80番なら越えられるでしょうね。金盾みたいな本格的なファイアーウォールでヘッダまでチェックすると弾けるかもしれませんけど、しばらくは判定のための経験を蓄積する必要があるんじゃないでしょうか。
というか、企業側からすれば、ブラウザの設定でwebsocketを切ればいいだけの気がします。もちろん、それで動かなくなるサイトもいくらか出てくるでしょうが、ファイアーウォールで禁止した際にも当然そうなるでしょうから、どのみち変わらない気がします。
Re: (スコア:0)
「Web」ってついてるのが既存のhttpスキームのパスを通過させるというニュアンスですので、httpで閲覧してるならほぼ通るはずかと。
> 矛と盾のような気が...
httpの1コネクション上で非同期（理想的にはリアルタイム）通信をするので、いままでできなかったことができる！系の進化ですが、個人的な比喩的には、ふつーの矛の先端に最強の盾をつけてぶんなぐったらなにこれ超最強じゃん！みたいな奇異感のある実装と思ってます。
現実、いままで複数コネクションだったら発生したオーバーヘッドがなくなるじゃん？に対して、でもコネクション管理（特に1コネクションあたりの伝送量の短期的見積もり）がよりめんどくなるじゃん？のトレードオフだと、個人的には思ってます。
Re: (スコア:0)
人はそれを円匙とい…わないか
Re: (スコア:0)
まずweb proxyは一定時間で勝手にコネクションをきるものが多いです
持続的な接続を要するweb socketだとまずこれが障害になります
サーバとクライアントが接続をずっと維持しようとしても
間に入るweb proxyは容赦なく切ります
次に暗号化していないコネクション（HTTP CONNECTメソッドを使わない接続）だと
web socketのハンドシェイクやその後のやり取りを理解できなくてエラーになります
多分一番うまくいくのではないかと予想するのは
httpsを使ってweb proxyを越えていく方法です
これであればweb proxyはただのHTTP CONNECTから始まる
一連のhttps通信だと勘違いするはずですが
一定時間で勝手にタイムアウトで切る設定は避けられません
Re: (スコア:0)
#2125897のACですが不安になったので調べてみました（あとだしジャンケンで失礼しますm(_ _)m）
proxy超えは以下のPOSTにもある通りRFC的にHTTP CONNECTがSHOULDだそうです。
ですので勘違いさすというより対応してよねー感のようですた。
http://onmessage.ws/wordpress/?p=214 [onmessage.ws]
> ここを見て頂くと分かりますが、proxyを経由する必要がある場合には、
>
> CONNECT example.com:80 HTTP/1.1
> Host: example.com
>
>
Re: (スコア:0)
同じACですが訂正です。
「RFC的に...」は間違いで「ドラフト（draft-ietf-hybi-thewebsocketprotocol-07）的に」が正しいです。
# RFC2616/2817の方に頭がひっぱられちゃった:3
# parosみたいにconnectでも中身みてやるぜーだと問題がおこりそう
Re: (スコア:0)
ユーザーの利便性のものではなく
ユーザーのweb access監視の為のものですからね
通常CONNECT後のTLSハンドシェイクの開始のチェックと
443ポート以外へのCONNECTメソッドの禁止ぐらいは行います
というか私が管理者であればそれぐらいの設定は入れます
でないとCONNECTで外部の任意のポートにアクセスし放題では
企業ネットワークにweb proxyを導入している意味がないですからね