問題タブ [g-wan]

Gwanに問題があります。いくつかのマシンで問題なく使用できましたが、現在のマシン CentOS 6.3 64bit Final、gwan バージョン 3.12.26、glibc バージョン 2.12 (安定版) に問題があります。

グァンを始めようとするたびに./gwan

で戻ります

完全なルート アクセス権があり、すべての.so共有ファイルが実行可能であることを確認し、SELinux がオフになっていることを確認しました。

皆さんが光を当てることができるものは何でも素晴らしいでしょう

gwanをウェブホスティングサーバーとして使用するには、gwanサーバー全体を再起動せずにvhostを追加/停止/削除するにはどうすればよいですか？

ありがとう

gwan は https 機能の使用方法に関するドキュメントをリリースしていないため、リバース プロキシを使用して https を受信し、http を gwan に渡そうとしています。
私の問題は次のとおりです。

1. リバース プロキシからのリクエストを識別する方法
2. http用とリバースプロキシからのリクエスト用のこれら2つの仮想ホスト間でkvストアを共有するにはどうすればよいですか? すべての仮想ホスト間ではなく、これら 2 つの仮想ホスト間でのみポインターを共有したいと考えています。

ありがとう

以下のコードを使用すると、ハンドラーはファイル以外の要求を認識しません (たとえば、要求には www フォルダーにファイルが含まれている必要があります)。他のすべてのリクエストでは、メインが呼び出されることさえありません。これがなぜなのかわかりません。

リクエスト:127.0.0.1/index.html
プリント:GET /index.html

リクエスト:127.0.0.1/favicon.ico
プリント:GET /favicon.ico

リクエスト:127.0.0.1/index
プリント:N/A

ご協力ありがとうございます。

Content-TypeCGIスクリプトのようにHTTPヘッダーを設定しようとしています。

でPHP：

またはでGo：

どちらも出力には影響しません。

これはどのように行うことができますか？

編集

また、パッケージGoを使用して、で次のことを試しました。CGI

しかし、エラーが発生します：

gwan (4.1.17) をフォルダーに展開した後、このフォルダーで gwan を実行します。正常に動作します。
この抽出されたフォルダーからプロジェクト フォルダー内のすべての古い gwan ファイルとフォルダーを置き換えると、gwan は c サーブレットを見つけることができませんが、www フォルダー内のファイルを見つけることはできます。

誰がこれを説明できますか?

Go コンパイラは、未使用の変数とインポートについて不平を言います。そのため、未使用の var/script が検出された場合、go スクリプトは gwan 内で実行できません。

この場合、実行中の場合、または単に開始できない場合、gwanは404エラーを提供します

この動作を回避する方法はありますか?

このページcaptcha.cが新しいバージョンで変更されないのはなぜgwanですか？（画像は変わりません）

この例は、古いバージョンでは正常に機能しました。

このテストコードに問題がある理由を教えてくれる人なら誰でも、GWAN が呼び出されるとクラッシュします。

gwan API ヘルプ: void aes_init(aes_t *ctx, u32 モード, u8 *key, u32 keylen);

私のテストコード:

すでに含まれていることを理解していないという理由だけで、別の暗号化ライブラリを実装するのは本当に嫌です。

ディレクトリ構造に 2 つのホスト エイリアスがあり、g-wan に正しく登録できません。私のフォルダ構造は次のとおりです。

/srv/gwan_linux64-bit/192.168.3.101_80/$dg.lcl
/srv/gwan_linux64-bit/192.168.3.101_80/$myapp
/srv/gwan_linux64-bit/192.168.3.101_80/#192.168.3.101
/srv/gwan_linux64 -bit/192.168.3.101_80/#192.168.3.101:gwan.klickitat.lcl
/srv/gwan_linux64-bit/192.168.3.101_80/#192.168.3.101:test.lcl

g-wan を起動すると、次のエラーが表示されます。

読み込み中.... * 未解決のエイリアス: 2

デフォルトの g-wan 構成のサンプル サーバー レポートから:

リスナー
5 ホスト: 192.168.3.101_80
仮想: $dg.lcl
ルート: #test.lcl
ルート: #gwan.klickitat.lcl
仮想: $myapp
ルート: #192.168.3.101

ご覧のとおり、g-wan は 2 つのルート エイリアスを追加のルートとして識別します。G-wan は 1 つのルート ホストのみを許可するため、2 つのエイリアスはブラウザーで 404 エラーで機能しません。各ホストは ping に適切に応答するため、DNS によって説明されます。仮想ホストとルート ホストは期待どおりに機能します。

考え？

追加の調査:

投稿エラーを修正し、プレゼンテーションを簡素化しました。これが簡潔であることがわかると思います。

私のホストファイルは、すべてのテストで次のとおりです。

127.0.0.1 localhost.klickitat.lcl ローカルホスト
192.168.3.101 gwan.klickitat.lcl test.lcl

ローカルサブネットと一致するように別の IP アドレスを使用し、仮想ホストを削除したことを除いて、テストと同じ例を実装しました。これは、テストの結果に影響しません。

デフォルトの gwan 構成に対する唯一の変更は次のとおりです。

• リスナーを 0.0.0.0_8080 から 192.168.3.101_8080 に変更しました
• ルート ホスト IP を #0.0.0.0 から #192.168.3.101 に変更しました
• 2 つのホスト エイリアス #192.168.3.101:gwan.klickitat.lcl および #192.168.3.101:test.lcl を追加

これは私のフォルダ構造です：

/srv/gwan_linux64-bit/192.168.3.101_8080
/srv/gwan_linux64-bit/192.168.3.101_8080/#192.168.3.101
/srv/gwan_linux64-bit/192.168.3.101_8080lick/#192.168.3.101:clitalkwan
. srv/gwan_linux64 ビット/192.168.3.101_8080/#192.168.3.101:test.lcl

これは、gwans に含まれるサーバー レポート アプリケーションによって報告された私の結果です。

3 ホスト: 192.168.3.101_8080
ルート: #test.lcl
ルート: #gwan.klickitat.lcl
ルート: #192.168.3.101

Gwan はエイリアスを認識せず、エイリアス URL にアクセスできません。私の結果はあなたの結果と矛盾しています。

この投稿の残りの部分は、私の環境の代替構成で gwan によってエイリアスが報告されることを説明することのみを目的としていますが、期待される結果にはいくつかの矛盾があります。フォルダー構造と結果を特定するだけです。

代替構成 1
/srv/gwan_linux64-bit/0.0.0.0_8080
/srv/gwan_linux64-bit/0.0.0.0_8080/#localhost
/srv/gwan_linux64-bit/0.0.0.0_8080/#localhost:gwan.klickitat.lcl
/srv /gwan_linux64-bit/0.0.0.0_8080/#localhost:test.lcl

結果:
3 ホスト: 0.0.0.0_8080
ルート: #localhost
エイリアス: 0.0.0.0:#gwan.klickitat.lcl
エイリアス: 0.0.0.0:#test.lcl

代替構成 2
/srv/gwan_linux64-bit/192.168.3.101_8080
/srv/gwan_linux64-bit/192.168.3.101_8080/#localhost
/srv/gwan_linux64-bit/192.168.3.101_8080/#localhost:gwan.klickitat.lcl
/srv /gwan_linux64-bit/192.168.3.101_8080/#localhost:test.lcl

結果:
3 ホスト: 192.168.3.101_8080
ルート: #localhost
エイリアス: 192.168.3.101:#gwan.klickitat.lcl
エイリアス: 192.168.3.101:#test.lcl

代替構成は機能しますが、エイリアスの命名はフォルダー構造での明示的な命名とは異なることに注意してください。リスナーは適切に設定されているようですが、ホスト レイスの生成方法に問題があるようです。ご希望があれば、さらにテストさせていただきます。