タグ付けされた質問 「jetty」

Apacheはポート：80でリクエストを受信し、ポート：8080でそれらをJettyにプロキシしています The proxy server received an invalid response from an upstream server The proxy server could not handle the request GET /. 私のジレンマ：すべてが正常に動作し、通常は（長い要求が処理されている数十秒の高速な要求、数秒または[OK] ）。リクエストの処理に時間がかかると（数分？）問題が発生します。 代わりに、ポート：8080でJetty に直接リクエストを発行すると、リクエストは正常に処理されます。そのため、問題はmod_proxyを使用しているApacheとJettyの間のどこかにある可能性があります。これを解決するには？ KeepAliveの設定に関連するいくつかの「トリック」を試してみましたが、運はありません。ここに私の現在の設定、提案がありますか？ #keepalive Off ## I have tried this, does not help #SetEnv force-proxy-request-1.0 1 ## I have tried this, does not help #SetEnv proxy-nokeepalive …

80 apache-2.2  jetty 

Jettyにポート8080上の任意のホストからの接続を提供したいです。私の/etc/default/jettyファイルには次のものがあります。 NO_START=0 JETTY_HOST= JETTY_PORT=8080 サーバーは、Lucid Lynx 32ビットサーバーAMIに基づくEC2スモールインスタンスです。APTは、マルチバースを有効にして構成されており、正規のパートナーリポジトリが有効になっています。Jettyは、パートナーリポジトリの6.1.22です。 を使用してjettyを起動するsudo /etc/init.d jetty startと動作し、localhostからの接続をリッスンしますが、他のリッスンはリッスンしません。- ubuntu@ip-10-224-70-51:/etc/network/if-pre-up.d$ sudo netstat -nlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 413/sshd tcp6 0 0 127.0.0.1:8080 :::* LISTEN 5655/jsvc tcp6 0 0 :::22 :::* LISTEN …

15 ubuntu-10.04  jetty 

ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 現在のスタックはApache + Tomcat + MySQLで、ProxyPassAJPを使用してApacheからTomcatにリクエストを送信します。また、同じサイトでWordpress用のPHPを実行しているため、作業.htaccessファイルが必要です。迷惑な問題（このStack Overflowページを参照）に対応して、代替スタックを検討しています。私たちは一般的にapacheが非常に好きであることに注意してください。しかし、この問題は致命的なものです。修正できない場合、Apacheは使用できません。 代替手段は次のとおりです。 Tomcatのみ Glassfish（Tomcatから分岐したJavaアプリサーバー） Jetty（Javaサーバー） 樹脂 LightTPD（軽量HTTPサーバー） Nginx（軽量HTTPサーバー） 私の考えでは、ソリューションは2つのキャンプに分類されます。Glassfishな​​どの純粋なJavaキャンプと、または、現在のApache + Tomcatなどの分割キャンプ。純粋なJavaソリューションのアイデアが気に入っています。可動部分が少ないほど、誤動作が少なくなるはずです。しかし、それらのいずれかがPHP、.htaccessファイルなどをサポートしていますか？ 理論的には、別の方法で分割を行うことができます-それらの機能を必要とするビットのみでApacheにプロキシするシンプルなフロントエンドがありますが、実際には要求の80％になります。 人々はどのような選択肢を提案しますか？

15 apache-2.2  nginx  tomcat  glassfish  jetty 

Jettyを使用してApache Solrインデックスを実行しています。以前に予想された最大長をはるかに超えるクエリがいくつかあり、サーバーが応答しないためにほとんどのクエリがデータを返さないという問題が発生しています（ブラウザーは「接続のリセット」と言います）。 これらのリクエストはブラウザを介して行われるのではなく、Apache_Solr_Service PHPライブラリを使用してプログラムで行われます。アプリケーションはクエリをHTTP GETリクエストとして受信することを想定しているため、POSTに切り替えてもこの問題は解決しません。 Jettyで許可されるHTTP GETクエリの最大長を増やすにはどうすればよいですか？ ありがとう！

14 jetty  solr 

Jetty（6.1.24）を使用して、httpのすべてのリクエストをhttpsにリダイレクトしたい。何らかの理由（私の無知）のために、これは私を避けています。これは私が持っているものです： <New id="redirect" class="org.mortbay.jetty.handler.rewrite.RedirectPatternRule"> <Set name="pattern">http://foobar.com/*</Set> <Set name="location">https://foobar.com</Set> </New> 応答では200を受け取ります-わかりました。本文はhttp上のページです。つまり、リダイレクトは発生しません。

11 jetty 

少し複雑なIDAM設定があります。 つまり、エンドユーザーのマシンとブラウザは親ADのあるネットワークにあり、Jettyベースのアプリケーションとそれが通信できるAD（ローカルAD）は別のネットワークにあります。 2つのADの間には双方向の信頼があります。親ネットワークのブラウザは、信頼済みサイトにローカルドメインを持っています。 Jettyサーバーの設定は次のとおりです。 ローカルADのプリンシパルに対して生成されたキータブファイルを使用する ローカルADで定義されたユーザーの下でWindowsサービスとして実行されている レルム、ドメイン-レルムマッピング、およびkdcは、ローカルADのドメインに対して定義されます それはspnegoを使用します-isInitiatorはfalseに設定されます。doNotPromptはtrueです。storeKeyはtrueです 問題は： テストとして、（すなわちローカルADにリンクされている）、ローカルネットワーク内のブラウザからサーバーにアクセスすると動作します私は、HTTPトラフィックに正しいKerberosのネゴシエーションを見ることができ、Kerberosのデバッグ情報がログに表示され、ユーザーは自動的に署名されています- 。鮮やかさ。 ただし、親ネットワーク内のブラウザーからサーバーにアクセスする（これは、ユーザーが操作する方法です）ことができません。ブラウザは401 unauthを取得しますが、資格情報を要求します。資格情報を入力すると、空白の画面が表示されます。次に、アドレスバーをクリックしてEnterキーを押すと、資格情報がリモートADとローカルADのどちらであるかに応じて、次のいずれかが行われます。 ローカルADの資格情報は、ログに最初からKerberosを使用して正常にログインします（GET要求、401非認証応答、Kerberosヘッダー要求など） リモートADの資格情報がログインしていない（GETリクエスト、401 UNAUTH応答は、何がNTLMヘッダーのようになります。Authorization: Negotiate <60 or so random chars>） いずれにせよ、それが促しているという事実は間違っています！ これらの症状の説明はありますか？私たちが持っているセットアップは私たちが望むことをすることができますか？ 上記の説明については何が間違っている可能性があるかについては、私が行ったように、Jettyサーバーに関して述べた構成はすべて正確である必要があります。詳細をお知らせいたします。ADまたは親ネットワークブラウザーのいずれかに関する構成は疑わしい可能性があります。これは、私の制御下になく、自分で確認するのではなく、報告された構成を持っているためです。

10 active-directory  kerberos  jetty  spnego 

圧縮が有効になっていないJettyサーバーがあります（これをここでテストしました）。圧縮を有効にするにはどうすればよいですか？

9 gzip  compression  jetty