potofo

Contributors, please absorb this pull request into the main banches.

WSLのRocky-Linux 9.3では正しく表示されています。 現象が起きているのはAWS Ubuntu-22.04です。

まず、Reverse-Proxyの設定(docker-compose.override.yml)は実施していません。 EdgeのDevToolの「ネットワーク」を確認したところ、以下のように表示されていました websocketのサイズが0Bとなっているので類似問題と思われます。 名前　　　　　　　　　　　　状況　　　種類　　　イニシエーター　　　　　　　　サイズ　　時間 pages.updatePost?path=%2F 　304　　　xhr　　　　47583-09d895d144a4698f.js:1　　555B 　　108ミリ秒 socket.io/?EIO=4&　　　　　　-　　　　websocket 17413.2f3d0cd2a0a07825.js:1　　0B　　　　26ミリ秒 Reverse-Proxyは動かしていないので、AWSのSG(Securiry Group)を見直してみます。

切り分け中ですが、中間状況報告です。 切り分けのためにWSL2にubuntu-22.04.6をインストールしてReverse Proxy無しコンテナ構成で docker-composeで動かしてみたところのWSL2のubuntuではEdit画面の左側ペインのMarkdownが 正しく表示されました。 また、WSL2の環境ではクライアントのEdgeのDevtoolsでwebsocketのログは見つかりませんでした。 AWS ubuntuで確認したこと ①UFWの設定は無効になっていることを確認 ②SG(Security Group)は全てのLANアダプタのIPとの間で3000/tcpを許可している 　⇒一時的に全解除して切り分けてみる ③https-portalを起動して確認（うまく起動できず設定を見直して再確認よてい） 　FQDN無しにも関わらずproductionで起動していたのが原因と思われる 　⇒STAGEをlocalにして再トライ予定(WSL2ではリプロデュースしないので恐らく無関係） WSL2との変化点としては以下の３点くらいです。 ①企業プロキシがある 　Growiがクライアントサイトのjavascriptを使っているならば考えられる ②AWS環境 　SGの設定（コンテナー間はLocalhost I/Fを使用したws/wss通信のはずなので関係なさそう) ③AWSのAMI(Amazon Machine Imageベースのubuntuである) 　関係なさそうですがAMI独自のwebsocketが通信できないケースがないか 　念のためRedhat系のAMIでも試してみます。 その他気になる点 ①FQDNアクセスではなくIPベースでアクセスしている点 ②企業Proxy通過時にHTTP通信の警告が出ている点

上記の企業プロクシが影響していないかと思い 仮説を立てました 検証内容EdgeのDevtoolでwebsocketが失敗委している通信先を確認 socket.io/?EIO=4&transport=websocketの詳細を表示 DevToolで確認した内容は以下の通りです 要求URL（AWSのサーバのIP) 　ws://XXX.XXX.XXX.XXX:3000/socket.io/?EIO=4&transport=websocket 応答ヘッダ― 　無し リクエストヘッダ 　記載あり このことから、ws即ちWebsocketの非TLS通信がProxyを通過できずEDIT画面のMarkdownテキストの 要求に応答がない事から、上手く動かないと考えています。 何らかの設定でWebsocket通信を使用しない方法はありますか？ また、 ①Markdownでエクスポート ②エクスポートしたMarkdownを入力 ③更新 ④再度「Edit」で開いた場合はMarkdownテキストは保持されまづが、DevtoolでWebsocketプロトコルを見ると 通信は失敗していますので、クライアントに保持されたデータで表示ができていると考えています。

仮説の企業Proxy問題を切り分けてみました。 やはり、ws/wssがProxy通過できていない模様です。 切り分けとして、AWS内部にEC2でWindowsを構築し、VPC内でGrowiに接続したところ、Markdownテキスト部が正しく表示されました。 同じサーバで企業Proxyの有無が変化点なので、企業Proxyをws/wssが通過できていないことが問題のようです。 >v7 のエディタは yjs というライブラリを常時利用する仕様になっているため、今のところは websocket が必須になります。 ありがとうございます。 v7ではWorkaroundは無いこと了解しました。

さらに切り分けを実施しました。 切り分けの結果、企業Proxyでwebsocketプロトロルが通過できるものと通過できないものがあることがわかりました。 今回のケースではA社のプロキシサービスでは通過できず、OSSなどで立ち上げたSquidやcernのhttpプロキシでは通過できるようです。 ひとまず、OSS側に振ることで、Makrdown テキスト(左側ペイン)を表示することができました。 websocketのOn/Offができることは理想ですが、無理に対応する必要もないかと思いました。 従って、本issue #8722はクローズいただいて結構です。

@microsoft-github-policy-service agree

I sees same issue. Claude Code for VS Code(Windows/Linux) does not work under corporate proxy environment. How ever Claude Code CLI do work.