[ https://issues.apache.org/jira/browse/KNOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sumit Gupta reassigned KNOX-476: -------------------------------- Assignee: Sumit Gupta > Honor and populate X-Forwarded-* headers > ---------------------------------------- > > Key: KNOX-476 > URL: https://issues.apache.org/jira/browse/KNOX-476 > Project: Apache Knox > Issue Type: New Feature > Components: Server > Affects Versions: 0.5.0 > Reporter: Kevin Minder > Assignee: Sumit Gupta > Priority: Critical > Fix For: 0.7.0 > > Attachments: reverse-proxy-header-filter.zip-safe > > > 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 -- This message was sent by Atlassian JIRA (v6.3.4#6332)