[jira] [Updated] (KNOX-476) Honor and populate X-Forwarded-* headers

["Kevin Minder (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KNOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Minder updated KNOX-476:
------------------------------
    Attachment: reverse-proxy-header-filter.zip-safe

Attached maven project with a prototype filter that does X-Forwarded-* header handling.

> 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)