Details

      Description

      Currently ATS provides only explicit forward proxying. It should support this transparently as well.

      Transparent means

      • No configuration on clients.
      • Origin server sees the client IP address as the source address of the cache fill request.

      This should be an option set via configuration variables because transparent proxying is not always the correct mode of operation. In addition, it requires a Linux kernel with TPROXY support and so will not run in all environments.

        Issue Links

          Activity

          Alan M. Carroll created issue -
          Hide
          Alan M. Carroll added a comment -

          Issue 1

          HttpTransact::check_request_validity only checks the request URL for the host and does not check the HOST field. This works for explicit proxy requests but most current web tools use the HOST field so without client configuration, ATS rejects the request with "400: Host Required In Request". I think this should be modified to do the check only in the transparent case as the explicit case should require the host in the URL.

          Issue 2

          It was mentioned to me that ATS had transparent forward proxy code at one point but it was (mostly) removed. In some cases there seems to be a remnant in the use of
          State::http_config_param::transparency_enabled
          which I presume is a flag used to enable transparent operation, although perhaps it is used for reverse proxying and therefore it is unclear whether it should be used for forward proxying.
          (see HttpTransact::initialize_state_variables_from_request for an example)

          Show
          Alan M. Carroll added a comment - Issue 1 HttpTransact::check_request_validity only checks the request URL for the host and does not check the HOST field. This works for explicit proxy requests but most current web tools use the HOST field so without client configuration, ATS rejects the request with "400: Host Required In Request". I think this should be modified to do the check only in the transparent case as the explicit case should require the host in the URL. Issue 2 It was mentioned to me that ATS had transparent forward proxy code at one point but it was (mostly) removed. In some cases there seems to be a remnant in the use of State::http_config_param::transparency_enabled which I presume is a flag used to enable transparent operation, although perhaps it is used for reverse proxying and therefore it is unclear whether it should be used for forward proxying. (see HttpTransact::initialize_state_variables_from_request for an example)
          Hide
          George Paul added a comment -

          For Issue 1, see section '14.23 Host' in the HTTP/1.1 RFC specification (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) for handling of "Host" field header.

          For Issue 2 you can safely assume that 'transparency_enabled' variable was used for indicating 'transparent forward proxy' mode AFAIR.

          -George

          Show
          George Paul added a comment - For Issue 1, see section '14.23 Host' in the HTTP/1.1 RFC specification ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html ) for handling of "Host" field header. For Issue 2 you can safely assume that 'transparency_enabled' variable was used for indicating 'transparent forward proxy' mode AFAIR. -George
          Alan M. Carroll made changes -
          Field Original Value New Value
          Link This issue depends on TS-320 [ TS-320 ]
          Hide
          Alan M. Carroll added a comment -

          The socket connection codes needs to be cleaned up before updating it to support transparent mode.

          Show
          Alan M. Carroll added a comment - The socket connection codes needs to be cleaned up before updating it to support transparent mode.
          Alan M. Carroll made changes -
          Assignee Alan M. Carroll [ amc ]
          Hide
          Mark Scifres added a comment -

          Hooray!

          Show
          Mark Scifres added a comment - Hooray!
          Leif Hedstrom made changes -
          Fix Version/s 2.1.2 [ 12315091 ]
          Hide
          Joe Chen added a comment -

          I concur with Alan. If this Transparent Proxy feature is implemented again, ATS will definitely have a larger foot-print of deployment in the Home Gateway (Home Router, in another name) that need a proxy HTTP caching server.

          Show
          Joe Chen added a comment - I concur with Alan. If this Transparent Proxy feature is implemented again, ATS will definitely have a larger foot-print of deployment in the Home Gateway (Home Router, in another name) that need a proxy HTTP caching server.
          Alan M. Carroll made changes -
          Link This issue depends on TS-338 [ TS-338 ]
          Hide
          Alan M. Carroll added a comment -

          Enabling transparency is a privileged operation and must be done deep in the socket code. The use of capabilities means that the privilege can be acquired in the top level code without change to the low level socket code and without running as root.

          Show
          Alan M. Carroll added a comment - Enabling transparency is a privileged operation and must be done deep in the socket code. The use of capabilities means that the privilege can be acquired in the top level code without change to the low level socket code and without running as root.
          Hide
          Alan M. Carroll added a comment -

          For configuration, I have currently set it up to be a server port attribute rather than an explicit configuration option. My view is that it is unclear that globally enabling transparency is a good idea and may break reasonable deployment scenarios. I have also split transparency in to two parts, inbound (client side) and outbound (server side). The implementation is already structured that way and there are use cases for at least one of the intermediate states.

          To configuration transparency, the server port attribute is set to "<", ">", or "=" instead of "C", "X", "T", or "D".

          "<" : Outbound (server side) transparency. The origin server sees the client IP address but the client sees an explicit proxy.
          ">": Inbound (client side) transparency. The client does not see the proxy, but the origin server sees an IP address assigned to ATS. This is a deployment that one might see deployed, to hide internal addresses on a corporate network.
          "=": Full transparency, both client and origin server see the connection as a direct one.

          Show
          Alan M. Carroll added a comment - For configuration, I have currently set it up to be a server port attribute rather than an explicit configuration option. My view is that it is unclear that globally enabling transparency is a good idea and may break reasonable deployment scenarios. I have also split transparency in to two parts, inbound (client side) and outbound (server side). The implementation is already structured that way and there are use cases for at least one of the intermediate states. To configuration transparency, the server port attribute is set to "<", ">", or "=" instead of "C", "X", "T", or "D". "<" : Outbound (server side) transparency. The origin server sees the client IP address but the client sees an explicit proxy. ">": Inbound (client side) transparency. The client does not see the proxy, but the origin server sees an IP address assigned to ATS. This is a deployment that one might see deployed, to hide internal addresses on a corporate network. "=": Full transparency, both client and origin server see the connection as a direct one.
          Leif Hedstrom made changes -
          Priority Minor [ 4 ] Critical [ 2 ]
          Hide
          Alan M. Carroll added a comment -

          Alpha quality patch put on branch ts-291. First pass documentation is available at
          http://people.apache.org/~amc/tiphares/home.html

          Show
          Alan M. Carroll added a comment - Alpha quality patch put on branch ts-291. First pass documentation is available at http://people.apache.org/~amc/tiphares/home.html
          Alan M. Carroll made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Leif Hedstrom made changes -
          Fix Version/s 2.1.3 [ 12315273 ]
          Fix Version/s 2.1.2 [ 12315091 ]
          Hide
          Leif Hedstrom added a comment -

          May I suggest that we merge this branch onto trunk as soon as possible? We just made a v2.1.2 release, so we have a stable snapshot, and we can start testing all these good changes asap on "trunk".

          Thanks!

          Show
          Leif Hedstrom added a comment - May I suggest that we merge this branch onto trunk as soon as possible? We just made a v2.1.2 release, so we have a stable snapshot, and we can start testing all these good changes asap on "trunk". Thanks!
          Hide
          Leif Hedstrom added a comment -

          Btw, "D" is no long supported / used (I think "D" was DNS proxy, right?). So if you have any code related to that, just eliminate the D option I think.

          Show
          Leif Hedstrom added a comment - Btw, "D" is no long supported / used (I think "D" was DNS proxy, right?). So if you have any code related to that, just eliminate the D option I think.
          Hide
          Alan M. Carroll added a comment -

          Yes, I will try to get to this tomorrow. I had been planning on doing the merge as soon as 2.1.2 went out.

          Tuesday, August 31, 2010, 9:31:05 PM, you wrote:

          Show
          Alan M. Carroll added a comment - Yes, I will try to get to this tomorrow. I had been planning on doing the merge as soon as 2.1.2 went out. Tuesday, August 31, 2010, 9:31:05 PM, you wrote:
          Hide
          Leif Hedstrom added a comment -

          Since this is committed / landed on trunk, can we close it ?

          Show
          Leif Hedstrom added a comment - Since this is committed / landed on trunk, can we close it ?
          Hide
          Alan M. Carroll added a comment -

          Changes merged to trunk.

          Show
          Alan M. Carroll added a comment - Changes merged to trunk.
          Alan M. Carroll made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Alan M. Carroll added a comment -

          Sort of tested on trunk. Future problems should be filed as separate bugs.

          Show
          Alan M. Carroll added a comment - Sort of tested on trunk. Future problems should be filed as separate bugs.
          Alan M. Carroll made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12507806 ] TS Workflow [ 12522737 ]
          Gavin made changes -
          Link This issue depends on TS-338 [ TS-338 ]
          Gavin made changes -
          Link This issue depends upon TS-338 [ TS-338 ]
          Gavin made changes -
          Link This issue depends on TS-320 [ TS-320 ]
          Gavin made changes -
          Link This issue depends upon TS-320 [ TS-320 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open In Progress In Progress
          103d 21h 57m 1 Alan M. Carroll 20/Jul/10 22:33
          In Progress In Progress Resolved Resolved
          63d 49m 1 Alan M. Carroll 21/Sep/10 23:23
          Resolved Resolved Closed Closed
          1m 42s 1 Alan M. Carroll 21/Sep/10 23:24

            People

            • Assignee:
              Alan M. Carroll
              Reporter:
              Alan M. Carroll
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development