On Sat, 2009-11-21 at 20:54 +0100, Stefan Wachter wrote: > Hi Oleg, > > thanks for your reply. I already have read the documentation and JavaDoc > carefully before I decided to ask on the mailing list. After reading the > docs again I still do not know how to set the three parameters secure, > tunnelled, and layered. >
* Plain: direct connection to the target or a proxy * Tunneled: connection to a proxy or a proxy chain using CONNECT method. Once the connection is established the proxy will simply forward whatever data it receives from the client to the target server or next proxy * Layered: another protocol is 'layered' over the existing connection. For example HTTPS via a proxy usually implies a tunneled and layered route. The client must establish a tunnel to the target server via the proxy and employ TLS/SSL as an additional protocol layer to encrypt/ decrypt transmitted data. The tunneling proxy transfers data between the client and the target without looking at it. A non tunneled route usually implies that the proxy must be able to look at the transmitted messages and rewrite them before passing on the recipient. > For example if I want to access a target host by https and there is a > single proxy host in between. As far as I understand the proxy could be > contacted either by https or by http. This means there are the following > two alternatives: > > 1: source host -> (http) -> proxy host -> (https) -> target host > 2: source host -> (https) -> proxy host -> (https) -> target host > I have never seen the second scenario ever used in real life. Usually the tunnel to the proxy is always established using plain HTTP. > What is the value for "secure" for these two alternatives? Can > alternative 1 be marked as secure (because the connection source -> > proxy is assumed to be in a secure intranet)? Is alternative 2 secure > because both enclosed connections are using https? > Secure flag is purely arbitrary. For instance plain routes within a controlled corporate network can be considered 'secure', whereas SSL connections with a weak cypher over a public network can be considered as insecure. The decision as to whether a route is secure or insecure is entirely up to you. HttpClient per default assumes that SSL connections can be considered as secure. Oleg > What should the values for tunnelled and layered be? > > Thanks for your attention & best regards, > > --Stefan > > > Am 21.11.2009 14:11, schrieb Oleg Kalnichevski: > > Stefan Wachter wrote: > >> Hi all, > >> > >> I want to write a custom implementation of the HttpRoutePlanner > >> interface. The only method to implement is: > >> > >> public HttpRoute determineRoute(HttpHost aTarget, HttpRequest > >> aRequest, HttpContext aContext) throws HttpException > >> > >> i.e. the method has to return an HttpRoute instance. There are various > >> constructors for an HttpRoute with the most general being: > >> > >> public HttpRoute(HttpHost target, InetAddress local, HttpHost[] > >> proxies, boolean secure, TunnelType tunnelled, LayerType layered) > >> > >> I can determine the array of proxies because of my application logic, > >> but I am unsure which values the remaining parameters (secure, > >> tunnelled, and layered) should take. > >> > >> Could someone shed some light on these parameters? How do they effect > >> the behaviour of HttpClient? > >> > > > > http://hc.apache.org/httpcomponents-client/tutorial/html/connmgmt.html#d4e442 > > > > http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/routing/RouteInfo.LayerType.html > > > > http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/routing/RouteInfo.TunnelType.html > > > > > > I hope this is enough > > > > Oleg > > > >> Best regards, > >> --Stefan > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
