Uploaded image for project: 'Stratos'
  1. Stratos
  2. STRATOS-676

LB shouldn't be re-writing http location header if Location is a hostname

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.0
    • Fix Version/s: 4.1.0 RC3
    • Component/s: Load Balancer
    • Labels:
      None

      Description

      After investigating the issue I found out that Stratos LB re-writes Http Location Header even if the Location header is a host name. This violates the spec and break most of the real world scenarios.

        Activity

        Hide
        imesh Imesh Gunaratne added a comment - - edited

        Fixed in master branch with commit revision 67a22ab51ef9288629979470648b3b2d7b831bba:

        • Added a configuration option to switch Location header rewrite functionality on and off. This option is now available in loadbalancer.conf, "rewrite-location-header".
        • If applications deployed in the PaaS do not use absolute URLs in Location headers with member IP addresses, this feature can be turned off.
        • If the above configuration option is turned on, load balancer will re-write Location headers if the incoming Location header URL host is an ip address (public/private) of a known member. The resulting outgoing Location header will have the cluster hostname of the corresponding member and the transport proxy port.
          To do this we have introduced a new hash map in load balancer context: Map<MemberIp, ClusterHostname>. This map will have both private and public ip addresses of all members.
        • In addition we have done a modification in messaging component to trigger Service Removed, Cluster Removed and Member Terminated event listeners before removing the relevant objects from the local topology data structure.
        Show
        imesh Imesh Gunaratne added a comment - - edited Fixed in master branch with commit revision 67a22ab51ef9288629979470648b3b2d7b831bba: Added a configuration option to switch Location header rewrite functionality on and off. This option is now available in loadbalancer.conf, "rewrite-location-header". If applications deployed in the PaaS do not use absolute URLs in Location headers with member IP addresses, this feature can be turned off. If the above configuration option is turned on, load balancer will re-write Location headers if the incoming Location header URL host is an ip address (public/private) of a known member. The resulting outgoing Location header will have the cluster hostname of the corresponding member and the transport proxy port. To do this we have introduced a new hash map in load balancer context: Map<MemberIp, ClusterHostname>. This map will have both private and public ip addresses of all members. In addition we have done a modification in messaging component to trigger Service Removed, Cluster Removed and Member Terminated event listeners before removing the relevant objects from the local topology data structure.
        Hide
        nirmal Nirmal Fernando added a comment -

        Hi Imesh,

        Well, this is the HTTP spec, and what it explains is the HTTP protocol and headers. Since, LB uses those headers, LB should respect the HTTP spec. I don't understand why it is so surprising to you.

        Point is Http spec clearly specify that the Location header will be used to 'redirect the recipient to a location other than the Request-URI'.

        Rationale is why would you need to do even touch the Http Location header if it's a host name? As the LB, it doesn't have any right/knowledge to change it.

        eg:
        LB fronts both PHP and Identity server clusters;

        In LOCATION=identity.stratos.com/a/b
        in HOST=php.stratos.com

        and the issue is LB re-write the Location header with php.stratos.com.

        Show
        nirmal Nirmal Fernando added a comment - Hi Imesh, Well, this is the HTTP spec, and what it explains is the HTTP protocol and headers. Since, LB uses those headers, LB should respect the HTTP spec. I don't understand why it is so surprising to you. Point is Http spec clearly specify that the Location header will be used to 'redirect the recipient to a location other than the Request-URI'. Rationale is why would you need to do even touch the Http Location header if it's a host name? As the LB, it doesn't have any right/knowledge to change it. eg: LB fronts both PHP and Identity server clusters; In LOCATION=identity.stratos.com/a/b in HOST=php.stratos.com and the issue is LB re-write the Location header with php.stratos.com.
        Hide
        imesh Imesh Gunaratne added a comment -

        I cannot see any points on how the Location header should be re-written in a load balancer in the HTTP specification
        IMO the title of this issue is misleading. What would be the rationale behind "LB shouldn't be re-writing http location header if Location is a hostname"?

        Show
        imesh Imesh Gunaratne added a comment - I cannot see any points on how the Location header should be re-written in a load balancer in the HTTP specification IMO the title of this issue is misleading. What would be the rationale behind "LB shouldn't be re-writing http location header if Location is a hostname"?
        Hide
        nirmal Nirmal Fernando added a comment -

        What else than HTTP spec Most of the real world cases you use host names. And especially if you send via a LB, you must use host names as a best practice.

        http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
        14.30 Location

        The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.

        Location = "Location" ":" absoluteURI

        An example is:

        Location: http://www.w3.org/pub/WWW/People.html

        Note: The Content-Location header field (section 14.14) differs
        from Location in that the Content-Location identifies the original
        location of the entity enclosed in the request. It is therefore
        possible for a response to contain header fields for both Location
        and Content-Location. Also see section 13.10 for cache
        requirements of some methods.

        Show
        nirmal Nirmal Fernando added a comment - What else than HTTP spec Most of the real world cases you use host names. And especially if you send via a LB, you must use host names as a best practice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 14.30 Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = "Location" ":" absoluteURI An example is: Location: http://www.w3.org/pub/WWW/People.html Note: The Content-Location header field (section 14.14) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see section 13.10 for cache requirements of some methods.
        Hide
        imesh Imesh Gunaratne added a comment -

        Yes we need to fix this but may be not by validating whether the Location header is a hostname.
        BTW which spec does this violate?

        Show
        imesh Imesh Gunaratne added a comment - Yes we need to fix this but may be not by validating whether the Location header is a hostname. BTW which spec does this violate?

          People

          • Assignee:
            imesh Imesh Gunaratne
            Reporter:
            nirmal Nirmal Fernando
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development