Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: Snapshot
    • Fix Version/s: 4.0 Alpha 2
    • Component/s: HttpConn
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      HttpClient requires a way of allowing a SOCKS proxy to be used on some
      connections without requiring that all created Sockets go through the proxy.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        1233d 10h 19m 1 Roland Weber 01/Sep/07 16:55
        Resolved Resolved Closed Closed
        71d 3h 16m 1 Roland Weber 11/Nov/07 19:12
        Mark Thomas made changes -
        Workflow jira [ 12580627 ] Default workflow, editable Closed status [ 12606363 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12557734 ] jira [ 12580627 ]
        Mark Thomas made changes -
        Workflow jira [ 12362798 ] Default workflow, editable Closed status [ 12557734 ]
        Roland Weber made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Roland Weber made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Roland Weber added a comment -

        ClientConnectionOperator.openConnection has access to HttpParams and HttpContext.
        I think that's enough to address this requirement by plugging in a custom CCO.

        HttpRoute does not make provisions for representing socks proxies. They could be inserted into the route as a proxy with socks: protocol, to make the connection manager socks-aware. That would throw off a lot of the upper layers though.
        Another way to represent the socks proxy in the route would be as the "local address". That should not cause problems in the upper layers, you just can't combine socks proxies and actual local addresses that way.

        cheers,
        Roland

        Show
        Roland Weber added a comment - ClientConnectionOperator.openConnection has access to HttpParams and HttpContext. I think that's enough to address this requirement by plugging in a custom CCO. HttpRoute does not make provisions for representing socks proxies. They could be inserted into the route as a proxy with socks: protocol, to make the connection manager socks-aware. That would throw off a lot of the upper layers though. Another way to represent the socks proxy in the route would be as the "local address". That should not cause problems in the upper layers, you just can't combine socks proxies and actual local addresses that way. cheers, Roland
        Oleg Kalnichevski made changes -
        Fix Version/s 4.0 Alpha 2 [ 12312475 ]
        Fix Version/s 4.0 Alpha 1 [ 12311646 ]
        Oleg Kalnichevski made changes -
        Assignee HttpComponents Dev [ httpclient-dev@jakarta.apache.org ]
        Oleg Kalnichevski made changes -
        Component/s HttpConn [ 12311099 ]
        Component/s HttpClient [ 12311010 ]
        Oleg Kalnichevski made changes -
        Fix Version/s 4.0 Alpha 1 [ 12311646 ]
        Fix Version/s 4.0 Final [ 12311094 ]
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 28421 12333893
        Hide
        Oleg Kalnichevski added a comment -
        Show
        Oleg Kalnichevski added a comment - HTTPCLIENT-448 has been marked as a duplicate of this bug. ***
        Hide
        Oleg Kalnichevski added a comment -

        Odi, All I am saying is that HttpParams might be a better place for proxy
        settings, as HostConfiguration is getting a little too messy IMO. I am not
        trying to say that we should not support multiple proxies and different proxy
        types. Let's just consider leveraging HttpParams as it has been specifically
        designed to allow parameter settings at client | method | connection level

        Oleg

        Show
        Oleg Kalnichevski added a comment - Odi, All I am saying is that HttpParams might be a better place for proxy settings, as HostConfiguration is getting a little too messy IMO. I am not trying to say that we should not support multiple proxies and different proxy types. Let's just consider leveraging HttpParams as it has been specifically designed to allow parameter settings at client | method | connection level Oleg
        Hide
        Ortwin Glück added a comment -

        Oleg,

        Proxy settings are 'manual routing' on the application layer of the protocol
        stack. Therefore proxy settings must remain a per host property in any case.
        Even if most proxy users will only use one proxy setting for all their
        connections, we must not restrict HttpClient to this most common case. I think
        it is an essential flexibility to be able to use a specific proxy per connection.

        At our company for instance, we have access to the intranets of some of our
        clients. It makes sense to set up one proxy server for each of those
        connections. With HttpClient I can then access any host in those intranets
        depending on the proxy setting.
        Also, if we ever want to implement PAC (auto config) we need to be able to use
        one setting per host.

        Show
        Ortwin Glück added a comment - Oleg, Proxy settings are 'manual routing' on the application layer of the protocol stack. Therefore proxy settings must remain a per host property in any case. Even if most proxy users will only use one proxy setting for all their connections, we must not restrict HttpClient to this most common case. I think it is an essential flexibility to be able to use a specific proxy per connection. At our company for instance, we have access to the intranets of some of our clients. It makes sense to set up one proxy server for each of those connections. With HttpClient I can then access any host in those intranets depending on the proxy setting. Also, if we ever want to implement PAC (auto config) we need to be able to use one setting per host.
        Hide
        Dennis Cook added a comment -

        Just one comment, please keep in mind those of us that use multi-homed hosts.
        There can be times where traffic on one NIC will require use a a proxy where
        traffic directed through another will not.

        Show
        Dennis Cook added a comment - Just one comment, please keep in mind those of us that use multi-homed hosts. There can be times where traffic on one NIC will require use a a proxy where traffic directed through another will not.
        Hide
        Oleg Kalnichevski added a comment -

        That's the point. I can't help thinking that proxy settings do not really belong
        to HostConfiguration at all, as one would very rarely need to change proxy on a
        per host basis. In the overwhelming majority of cases there's only one proxy the
        user would want to deal with. So, I'd rather see proxy settings moved to
        HttpParams, but that would be too radical for 3.0.

        Oleg

        Show
        Oleg Kalnichevski added a comment - That's the point. I can't help thinking that proxy settings do not really belong to HostConfiguration at all, as one would very rarely need to change proxy on a per host basis. In the overwhelming majority of cases there's only one proxy the user would want to deal with. So, I'd rather see proxy settings moved to HttpParams, but that would be too radical for 3.0. Oleg
        Hide
        Sam Berlin added a comment -

        Whatever's easiest for you folks is fine for us. We're going to continue using
        a customized version of HttpClient for the indefinite future, so it doesn't
        much matter where it goes in the official version.

        Storing the SOCKS info in HostConfiguration was more because we consider a
        SOCKS proxy to be on the same footing as an HTTP Proxy (in the sense that
        they're both proxies), and HTTP proxy was stored in HostConfig.

        Show
        Sam Berlin added a comment - Whatever's easiest for you folks is fine for us. We're going to continue using a customized version of HttpClient for the indefinite future, so it doesn't much matter where it goes in the official version. Storing the SOCKS info in HostConfiguration was more because we consider a SOCKS proxy to be on the same footing as an HTTP Proxy (in the sense that they're both proxies), and HTTP proxy was stored in HostConfig.
        Hide
        Michael Becke added a comment -

        I agree that this probably won't make it in until the release after next (4.0). In the mean time we could
        refactor it into a stand-alone Socket factory and include it in contrib. How does that sound?

        Mike

        Show
        Michael Becke added a comment - I agree that this probably won't make it in until the release after next (4.0). In the mean time we could refactor it into a stand-alone Socket factory and include it in contrib. How does that sound? Mike
        Hide
        Oleg Kalnichevski added a comment -

        Somehow I can't help thinking that SOCKS parameters do not really belong to
        HostConfiguration. I would rather see them in HttpState or in the HttpParam
        collection. I suggest we address this problem in the 3.0 (4.0, that is) timeframe.

        Oleg

        Show
        Oleg Kalnichevski added a comment - Somehow I can't help thinking that SOCKS parameters do not really belong to HostConfiguration. I would rather see them in HttpState or in the HttpParam collection. I suggest we address this problem in the 3.0 (4.0, that is) timeframe. Oleg
        Hide
        Sam Berlin added a comment -

        Credit for the previous diff goes to Sumeet Thadani, another developer on our team.

        Show
        Sam Berlin added a comment - Credit for the previous diff goes to Sumeet Thadani, another developer on our team.
        Hide
        Sam Berlin added a comment -

        Created an attachment (id=11253)
        example diff from a modified 2.0rc2

        Show
        Sam Berlin added a comment - Created an attachment (id=11253) example diff from a modified 2.0rc2
        Sam Berlin created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Sam Berlin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development