[
https://issues.apache.org/jira/browse/KNOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Minder updated KNOX-476:
------------------------------
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
was:
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
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
> 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
>
>
> 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)
