[
https://issues.apache.org/jira/browse/KNOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624874#comment-14624874
]
Kevin Minder commented on KNOX-476:
-----------------------------------
[~sumit.gupta] < Take a look at the utility in the attached
xforwarded-client-util.patch. I'm not sure if we should check it in or what
but I'd like your review so see if you think it would be useful for clients
like Ambari to help them consume X-Forwarded-* headers and generate proxy
friendly URLs.
> 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,
> xforwarded-client-util.patch
>
>
> 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)
