Hi Andrei,
thanks for verification!
Regards,
Pavel
On 29/01/15 11:03, Andrei Nicolau wrote:
> Hi Pavel,
>
> We tested the 1.10-SNAPSHOT jar and the issues are fixed.
> We see the same behavior both on Linux and Win . Also the proxy is not
> bypassed anymore.
>
> Thanks a lot for taking care of this .
>
> Best regards,
> Andrei
>
> On 01/23/2015 06:51 PM, Andrei Nicolau wrote:
>> That sounds great Pavel.
>>
>> I filed the issue under https://java.net/jira/browse/TYRUS-394 . If
>> there is anything I didn't mention in it, please let me know and I'll
>> update it.
>>
>> Regarding the RFC you mentioned I still can't figure out why any
>> explicit usage of a proxy would result in a direct connection.
>> As I see it, if I set a proxy for a connection, I do it because I
>> need/expect my connection to to through that proxy ip/server, not
>> because I just feel like using a proxy.
>>
>> Thanks a lot for your willingness to fix this issue and for your
>> prompt answers.
>>
>> Best of wishes,
>> Andrei
>>
>> On 01/23/2015 04:41 PM, Pavel Bucek wrote:
>>>
>>> Hi Andrei,
>>>
>>> the implemented behavior is side-effect of
>>> http://tools.ietf.org/html/rfc6455#section-4.1 (see chapter 4.1.3).
>>> In short, the RFC defines the ordering of proxies we should use (when
>>> available).
>>>
>>> My previous conclusion was little bit hasty, even thought I really
>>> thought it works as I described. The problem you see is that for some
>>> reason, windows are throwing ConnectException, which is IOException
>>> and that is being rethrown, thus ending "connect" process. For some
>>> reason, we handle TimeoutException differently - we just close the
>>> transport and try next proxy.
>>>
>>> Anyway, given that I know about some other differences in thrown
>>> exceptions from networking stack on different platforms, I'm open to
>>> change this, and hopefully unify the behavior by that change.
>>>
>>> I belive that the change should be as simple as:
>>>
>>> - remove special handling for TimeoutException
>>> - when proxy is set, don't add "Proxy.NO_PROXY" fallback.
>>>
>>> Can you please file an issue?
>>>
>>> Thanks,
>>> Pavel
>>>
>>> On 23/01/15 15:02, Andrei Nicolau wrote:
>>>> Hi Pavel,
>>>>
>>>> I am curious about the reasons behind this implementation. It seems
>>>> strange to use direct connection as a fallback when setting a proxy.
>>>>
>>>> Here is the stack trace :
>>>>
>>>> java.net.ConnectException: Connection timed out: no further information
>>>> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>>>> at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
>>>> at
>>>> org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:206)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:154)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:258)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:552)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
>>>>
>>>> at
>>>> org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
>>>> at
>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
>>>>
>>>>
>>>> at
>>>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
>>>>
>>>>
>>>> at java.lang.Thread.run(Unknown Source)
>>>>
>>>> Regards,
>>>> Andrei
>>>>
>>>> On 1/23/2015 11:32 AM, Pavel Bucek wrote:
>>>>>
>>>>> Hi Andrei,
>>>>>
>>>>> both our transports (grizzly and jdk 7) do try to connect to proxy
>>>>> (when set), but if the connection fails, it will continue trying with
>>>>> other proxies. Ultimately it will hit the fallback, which is "direct
>>>>> connection"; meaning that if you set "fake" proxy, it will fail, but
>>>>> Tyrus will still try to connect to the host.
>>>>>
>>>>> I guess we could introduce configurable option, which would try just
>>>>> the first valid proxy and fail if we cannot connect to the proxy. Feel
>>>>> free to file an enhancement request at
>>>>> https://java.net/jira/browse/TYRUS.
>>>>>
>>>>> Interesting statement (for me) is that on windows, connection fails
>>>>> :-) Can you please share the stack trace?
>>>>>
>>>>> Regards,
>>>>> Pavel
>>>>>
>>>>> On 23/01/15 10:15, Andrei Nicolau wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to create a websocket client to connect to a server
>>>>>> through
>>>>>> a proxy.
>>>>>> Everything works fine if the proxy is a valid one but whenever I
>>>>>> use a
>>>>>> fake proxy ( random ip / port ), instead of failing it still
>>>>>> connects to
>>>>>> the server.
>>>>>>
>>>>>> Did anyone encounter this issue and maybe knows a fix ?
>>>>>>
>>>>>> p.s. I've tested this on two linux machines and on a windows
>>>>>> machine. On
>>>>>> the windows machine it behaves as it should.
>>>>
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> http://www.avast.com
>>>>
>>
>