On Mon, 2009-11-23 at 15:44 +0100, Stefan Wachter wrote: > Hi Oleg, > > thank you for the additional information. > > You said, that the "secure" flag is "purely" arbitrary". Does this flag > have no effect at all on the way HttpClient behaves? Can I always set > this flag simply to "false"?
You can, but this will prevent HttpClient from sending cookies marked as secure back to the origin server. > > Would the following rule for setting the TunnelType property correct? > > 1. Whenever there is a proxy between between the source and the target > host set the tunnel type to "TunnelType.TUNNELLED". No. Direct connection to the proxy does not always require tunneling. Tunneling is necessary only when sending data through a proxy using CONNECT method. That is, when the proxy cannot 'see' the data being transferred. > 2. Otherwise set the tunnel type to "TunnelType.PLAIN". > > Would the following rule for setting the LayerType property correct? > > 1. Whenever the target host is accessed by https set the layer type is > set to "LayerType.LAYERED". > 2. Otherwise set the layer type to "LayerType.PLAIN". > No. Layering can be used only if the connection is tunneled. The default logic is actually fairly simple: direct HTTP connection: TunnelType.PLAIN, LayerType.PLAIN direct HTTPS connection: TunnelType.PLAIN, LayerType.PLAIN proxied HTTP connection: TunnelType.PLAIN, LayerType.PLAIN proxied HTTPS connection: TunnelType.TUNNELED, LayerType.LAYERED There can be some _really_ unusual cases when one might want to have a tunneled connection, which is non layered, hence the distinction between tunneling and layering. Oleg > Thanks you for your help & best regards, > > --Stefan > > > Am 23.11.2009 11:47, schrieb Oleg Kalnichevski: > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
