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

          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
          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.
          Hide
          Mark Scifres added a comment -

          Hooray!

          Show
          Mark Scifres added a comment - Hooray!
          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.
          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.
          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
          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.
          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.

            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