Hi Oleg,
I still struggle with the implementation of my HttpRoutePlanner.
I try to establish an HTTPS connection to a target host via a proxy. You
said that "usually the tunnel to the proxy is established using plain
HTTP". When I try to return a route where the first hop (the hop to the
proxy) is using HTTP then the secure flag of the route must not be
"true". If you try then the following exception is raised:
java.lang.IllegalStateException: Unable to establish route.
planned = HttpRoute[{s}->http://localhost:8008->https://www.gmx.net]
current = HttpRoute[{}->http://localhost:8008->https://www.gmx.net]
I tracked the reason down and found that the isSecure method of the
PlainSocketFactory always returns false. This means that if the proxy is
accessed using http then the route must not be flagged to be secure. You
said that if a route is flagged unsecure then "this will prevent
HttpClient from sending cookies marked as secure".
To summarize: If I want to contact a target host via a proxy by https
and want to have cookies that are marked to be secure to be sent then I
have to use https to contact the proxy and mark the route as being
secure. Right?
In your last response you wrote, that for proxied https connections
TunnelType.TUNELLED and LayerType.LAYERED should be choosen. When I
return a route that uses https to access the proxy and the target host,
that has its secure flag set to true and that is tunneled and layered, I
get the following exception:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at
com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123)
at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147)
at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:101)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:381)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554)
What is going wrong here? Does it mean that the proxy host needs to have
a certifacate that is signed by a trusted certifaction authority?
Next try: If I choose a route that uses http to access the proxy host
and https to access the target host and use TunnelType.PLAIN and
LayerType.PLAIN then the route works. Yet, this route can not be marked
to be secure. This means that secure cookies are not sent!
Thanks for you patience and help,
--Stefan
Am 24.11.2009 10:38, schrieb Oleg Kalnichevski:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
