Uploaded image for project: 'Apache Knox'
  1. Apache Knox
  2. KNOX-476

Honor and populate X-Forwarded-* headers

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • 0.5.0
    • 0.6.0
    • Server
    • None

    Description

      If we could do a better job of honoring the X-Fowarded-* header in Knox it may elimination some of the extra configuration necessary to support load balancers. In addition if we can populate and propagate these values to the back end services we could potentially eliminate the need for much of the rewriting that is required therefore greatly simplifying the work that needs to be done in Knox for each service.

      X-Forwarded-Host
      http://tools.ietf.org/html/rfc7239#section-5.3
      Examples:
      X-Forwarded-Host: en.wikipedia.org:80
      X-Forwarded-Host: en.wikipedia.org

      X-Forwarded-Proto
      http://tools.ietf.org/html/rfc7239#section-5.4
      Examples:
      X-Forwarded-Proto: https

      I've also seen X-Forwarded-Port used. This should probably be supported although I think the port would more correctly be in the X-Forwarded-Host header.

      X-Forwarded-Context
      This is more Knox specific
      Examples
      X-Forwarded-Context: /gateway/red
      X-Forwarded-Context: /gateway/red/webhbase
      This is required since Knox aggregates may REST APIs under a single port that might otherwise have namespace collisions. Especially for REST APIs that don't provide their own top level resource identifier like Stargate. For services like oozie or webhcat/templeton the context would not include that information since those services would naturally add that information to the returned URLs. The expectation is that the service will add this value as a prefix to any generated fully qualified URL. In addition any fully qualified URL accepted by the service should strip this value from fully qualified URLs received in request bodies.

      X-Forwarded-Port
      Examples:
      X-Forwarded-Proto: 8443
      The need for this is less clear. The X-Forwarded-Host clearly does seem to contain the port information for non-default ports (i.e. 80 or 443). So this may not be required.
      http://mattrobenolt.com/handle-x-forwarded-port-header-in-django/
      http://stackoverflow.com/questions/19084340/real-life-usage-of-the-x-forwarded-host-header

      Examples can also be seen here:
      http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

      Attachments

        1. reverse-proxy-header-filter.zip-safe
          17 kB
          Kevin Minder
        2. xforwarded-client-util.patch
          35 kB
          Kevin Minder

        Issue Links

          Activity

            People

              sumit.gupta Sumit Gupta
              kminder Kevin Minder
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: