問題タブ [jetty-httpclient]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1782 参照

java - jettyhttpclientを使用するためのjarの依存関係

(netbeansで)jetty httpclientを使用したいのですが、jarの依存関係の数が最も少なくなっています。すべてのjarファイルをjettylibフォルダーからプロジェクトにインポートできることは知っていますが、依存関係の最小数と、これをどのようにして見つけたかを知りたいですか?jarの依存関係を見つけるためのツールはありますか?

0 投票する
1 に答える
1874 参照

java - Jetty HTTPClient で HTTP パイプラインを使用する

HTTPClient (org.eclipse.jetty.client.HttpClient) を使用して HTTP リクエストをパイプライン処理する方法を理解しようとしています。

非同期モードでいくつかの ContentExchange インスタンスを作成し、それぞれに send() メソッドを適用しようとしましたが、各 HTTP 要求は次の要求が送信される前に応答を待ちました。

この場合のコード スニペットを提供していただけますか?

0 投票する
1 に答える
1425 参照

java - 比較的小さな値を返す available() メソッドでストリームを使用すると、Jetty HttpClient が POST でクラッシュする

Jetty HttpClient を使用して、本文が数 MB 程度の POST リクエストを送信します。Jetty にリクエストのストリーミングをできるだけ早く開始してもらいたいので、setRequestContentSourceメソッドを使用します。

問題は、比較的小さな値 (4096 など) を返す available() メソッドで入力ストリームを使用すると、Jetty が次のエラーでクラッシュすることがあることです。

これは決定論的ではなく、ストリームの read() メソッドに Thread.sleep(10) を配置すると問題が解決するようです。このエラーは、パイプされたストリームが使用されている場合にも修正できます。これら 3 つのことから、これはある種の競合状態であると思われます。

これは Jetty のバグだと思いますが、そのようなシナリオで奇妙なことをしていないかどうかを確認したいと思います。

0 投票する
0 に答える
443 参照

java - Jetty HttpClient でピア証明書にアクセスする

Jetty HttpClient を使用して HTTPS リクエストを作成しています。SSL 接続を確立した後、データを送信する前に、目的のサーバーと通信していることを確認したいと思います。基本的に、リクエストを www.foo.com に送信する場合、サーバーにそのドメイン名の証明書があることを確認します。

これを達成する 1 つの方法は、自分自身を作成し​​、それを に与えられたTrustManager作成に使用することです。トラスト マネージャーで使用可能なコールバックは次のとおりです。SslContextFactoryHttpClient

すべての場合において、証明書にはアクセスできますが、元の要求にはアクセスできません (元のドメイン名が必要です)。

HttpExchange思いつく 2 番目のオプションは、要求を行うために使用している子孫からピア証明書にアクセスすることです。たとえば、 を呼び出した後HttpClient.send(exchange)、ピア証明書にアクセスして検証を実行できました。SSLEngineただし、交換から SSL 情報 (ピア証明書またはSSLSocketオブジェクトのいずれか) にアクセスする方法はないようです。

さらに、HttpClient 自体は証明書の内容の検証を行っていないようです。これは、検証ロジックをプラグインする場所がなく、HttpClient が DNS スプーフィング攻撃に対して脆弱であることを意味します (トピックの説明については、http: //www.cs.utexas.edu/~shmat/shmat_ccs12.pdf を参照してください)。 )。

サーバー名の検証をどこにプラグインできるかについて、誰かがヒントを与えることができますか?

0 投票する
1 に答える
1585 参照

ssl - Jetty HttpClient 9(9.0.0.M5)SSLContextFactoryのTrustAllフラグが機能していませんか?

Jetty HttpClient 9を使用して単純なWebクロールを実行していますが、HTTPSで機能させることができないようです。同期GETリクエストを行う次の簡単なコード...

SslContextFactoryを作成するときにTrustAllフラグを使用すると、SSLに関連しているように見える次の例外が発生します...

私はここで何が間違っているのですか?これは、Jetty HttpClientにすべてのSSL接続を信頼させる正しい方法ですか?そうでない場合、適切なアプローチは何ですか?

0 投票する
2 に答える
621 参照

java - Jetty 9 を使用して HttpClient からの応答を取得する際のエラー

Jetty と HttpClient クラスを使用して、外部サーバーからコンテンツを取得したいと考えています。HttpServletResponse取得したレスポンスを as としてコピーし、クライアント (ブラウザ) に返したいと思います。私は何かを試みましたが、成功することはできません。私は内部クラスを乗り越えていないと思います。

これが私のコードです:

エラーは次のように割り当てresponseています。

エンクロージング型で定義されているため、最終的なローカル変数の応答を割り当てることができません

パラメータに使用finalしないと、次のようなエラーもあります。

別のメソッドで定義された内部クラス内の非最終変数応答を参照することはできません

原因は何ですか?

0 投票する
3 に答える
148 参照

java - Jetty HTTPClient に含まれるもの

Jetty を使用して、websocket を使用する HTTP サーバーに接続しようとしています。問題は、コンパイラがクラス HTTPClient を解決できないことです。ここでstackoverflowを検索しましたが、解決策が見つかりましたが、有用なリソースへのリンクが利用できなくなりました...この例を実行するには、どのJARを含める必要がありますか? http://wiki.eclipse.org/Jetty/Tutorial/HttpClient

このページには何も書かれていません...ありがとう

0 投票する
0 に答える
197 参照

ssl - Jetty HttpClient での SSL 再ネゴシエーションの失敗

Jetty の ProxyServlet に基づくプロキシ サーブレットを使用していますが、リモート サーバーにリクエストをプロキシしようとすると、プロキシの HttpClient で SSL 再ネゴシエーションの失敗が原因で断続的な 502 レスポンスが発生します。Wireshark のトレースは、SSL ハンドシェイクが完了したことを示していますが、HttpClient は別の Client Hello パケットを送信してネゴシエーションをやり直しています。リモート サーバー (この場合は F5) は SSL 再ネゴシエーションを許可しないように構成されているため、接続がシャットダウンされ、プロキシされた要求が失敗します。

プロキシの HttpClient を構成するときに SslContextFactory.setRenegotiationAllowed(false) を呼び出してみましたが、これにより、リクエストがプロキシ内で内部的に失敗するだけです。デバッグ レベルのロギングでは、以下に示す出力が得られます。「再ネゴシエーションが拒否されました」というメッセージに注意してください。これにより、ストリームが閉じられ、その後プロキシされた要求を出力ストリームに書き込もうとすると、Connection Closed 例外が発生します。

では、HttpClient が SSL 再ネゴシエーションを実行する必要があると判断する原因は何でしょうか? また、この問題を回避するにはどうすればよいでしょうか? F5 の構成を変更して SSL 再ネゴシエーションを許可することはできません。問題は断続的であり、再現性はさまざまであり、タイミング コンポーネントが存在する可能性があることを示唆しています。

Java 1.8.0_66 で Jetty 9.2.13.v20150730 を使用しています。

2015-10-26 15:23:04,987 | DEBUG | vletModel-46-263 | SslConnection | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | SslConnection@276888f4{NEED_WRAP,eio=-1/-1,di=-1} -> HttpConnectionOverHTTP@76f2815f(l:/9.32.133.96:51386 <-> r:mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443,closed=false)[HttpChannelOverHTTP@44d24828(exchange=HttpExchange@3284d378 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@74d58ca9(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@501e585d(rsp=IDLE,failure=null)[HttpParser{s=START,0 of 0}]]] fill enter 2015-10-26 15:23:04,987 | DEBUG | vletModel-46-263 | ChannelEndPoint | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | filled 1006 SelectChannelEndPoint@57eceb70{mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443<->51386,Open,in,out,-,-,15/30000,SslConnection}{io=0,kio=0,kro=1} 2015-10-26 15:23:04,987 | DEBUG | vletModel-46-263 | SslConnection | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | SslConnection@276888f4{NEED_WRAP,eio=1006/-1,di=0} -> HttpConnectionOverHTTP@76f2815f(l:/9.32.133.96:51386 <-> r:mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443,closed=false)[HttpChannelOverHTTP@44d24828(exchange=HttpExchange@3284d378 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@74d58ca9(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@501e585d(rsp=IDLE,failure=null)[HttpParser{s=START,0 of 0}]]] filled 1006 encrypted bytes 2015-10-26 15:23:04,987 | DEBUG | vletModel-46-263 | SslConnection | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | SslConnection@276888f4{NEED_WRAP,eio=0/-1,di=977} -> HttpConnectionOverHTTP@76f2815f(l:/9.32.133.96:51386 <-> r:mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443,closed=false)[HttpChannelOverHTTP@44d24828(exchange=HttpExchange@3284d378 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@74d58ca9(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@501e585d(rsp=IDLE,failure=null)[HttpParser{s=START,0 of 0}]]] unwrap Status = OK HandshakeStatus = NEED_WRAP bytesConsumed = 1006 bytesProduced = 977 2015-10-26 15:23:04,988 | DEBUG | vletModel-46-263 | SslConnection | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | SslConnection@276888f4{NEED_WRAP,eio=0/-1,di=977} -> HttpConnectionOverHTTP@76f2815f(l:/9.32.133.96:51386 <-> r:mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443,closed=false)[HttpChannelOverHTTP@44d24828(exchange=HttpExchange@3284d378 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@74d58ca9(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@501e585d(rsp=IDLE,failure=null)[HttpParser{s=START,0 of 0}]]] renegotiation denied 2015-10-26 15:23:04,988 | DEBUG | vletModel-46-263 | SslConnection | 73 - org.eclipse.jetty.util - 9.2.13.v20150730 | SslConnection@276888f4{NEED_WRAP,eio=-1/-1,di=977} -> HttpConnectionOverHTTP@76f2815f(l:/9.32.133.96:51386 <-> r:mail.notes.collabservdaily.swg.usma.ibm.com/9.70.230.131:443,closed=false)[HttpChannelOverHTTP@44d24828(exchange=HttpExchange@3284d378 req=TERMINATED/null@null res=PENDING/null@null)[send=HttpSenderOverHTTP@74d58ca9(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator{s=START}],recv=HttpReceiverOverHTTP@501e585d(rsp=IDLE,failure=null)[HttpParser{s=START,0 of 0}]]] fill exit