[
https://issues.apache.org/jira/browse/KNOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380057#comment-14380057
]
Axton Grams commented on KNOX-476:
----------------------------------
I have an interest in this so that I have a record of transactions collected by
Ranger. This would be helpful for compliance reasons and to facilitate
inquiries into access audit logs.
> 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
> Priority: Critical
> Fix For: 0.6.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)
