[
https://issues.apache.org/jira/browse/KNOX-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971796#comment-15971796
]
Larry McCay commented on KNOX-924:
----------------------------------
This is the relevant section and language (from same document that you
reference) that this feature was implemented against:
https://tools.ietf.org/html/rfc7239#section-5.3
5.3. Forwarded Host
The "host" parameter is used to forward the original value of the
"Host" header field. This can be used, for example, by the origin
server if a reverse proxy is rewriting the "Host" header field to
some internal host name.
The syntax for a "host" value, after potential quoted-string
unescaping, MUST conform to the Host ABNF described in Section 5.4 of
[RFC7230].
5.4. Forwarded Proto
The "proto" parameter has the value of the used protocol type. The
syntax of a "proto" value, after potential quoted-string unescaping,
MUST conform to the URI scheme name as defined in Section 3.1 in
[RFC3986] and registered with IANA according to [RFC4395]. Typical
values are "http" or "https".
For example, in an environment where a reverse proxy is also used as
a crypto offloader, this allows the origin server to rewrite URLs in
a document to match the type of connection as the user agent
requested, even though all connections to the origin server are
unencrypted HTTP.
5.5. Extensions
Extensions allow for additional parameters and values. Extensions
can be particularly useful in reverse proxy environments. All
extension parameters SHOULD be registered in the "HTTP Forwarded
Parameter" registry. If certain extensions are expected to have
widespread deployment, they SHOULD also be standardized. This is
further discussed in Section 9.
You can see the discussion in https://issues.apache.org/jira/browse/KNOX-476.
I believe that the implementation clearly does follow those guidelines - unless
I missing some nuance in your observations.
The way that I interpret the language in that section is that Knox rewriting
needs to make sure that we rewrite the relevant segments of the URL in such a
way that the useragent will be directed back through the same host and port as
was originally requested.
Are you saying that it is only broken in the redirection Location header
rewriting?
If you are encountering a scenario where this rewriting is somehow
inappropriate then I would like to hear more specifics.
> X-forwarded-host, X-forwared-port header behavior when there are multiple
> balancers/proxys causing redirection problems
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-924
> URL: https://issues.apache.org/jira/browse/KNOX-924
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Jeffrey E Rodriguez
> Assignee: Jeffrey E Rodriguez
> Priority: Critical
>
> When there are other intermediaries between client and Knox it is possible to
> cause Knox rewrites to not go to the gateway host but in fact the
> gateway.host reflects X-forwar-host.
> e.g.
> "curl -v -k -u guest:guest-password -H X-Forwarded-Proto: http -H
> X-Forwarded-For: jeff -H X-Forwarded-Context:/ordexecvalid-prod/data/ -H
> X-Forwarded-Port: 843 -H X-Forwarded-Host: myfoo.com -i
> https://knox1.fyre.ibm.com:8443/gateway/default/webhdfs/v1/apps/hbase/data/hbase.id?op=OPEN
> * Trying 9.30.57.135...
> * TCP_NODELAY set
> * Connected to knox1.fyre.ibm.com (9.30.57.135) port 8443 (#0)
> * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate: localhost
> * Server auth using Basic with user 'guest'
> > GET
> > /gateway/default/webhdfs/v1//iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?op=OPEN
> > HTTP/1.1
> > Host: knox1.fyre.ibm.com:8443
> > Authorization: Basic Z3Vlc3Q6Z3Vlc3QtcGFzc3dvcmQ=
> > User-Agent: curl/7.51.0
> > Accept: */*
> > X-Forwarded-Proto: http
> > X-Forwarded-Server: myfooserver.com
> > X-Forwarded-For: jeff
> > X-Forwarded-Context: /ordexecvalid-prod/data/
> > X-Forwarded-Port: 843
> > X-Forwarded-Host: myfoo.com
> < HTTP/1.1 307 Temporary Redirect
> HTTP/1.1 307 Temporary Redirect
> < Date: Sun, 16 Apr 2017 00:18:44 GMT
> Date: Sun, 16 Apr 2017 00:18:44 GMT
> < Set-Cookie:
> JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> Set-Cookie:
> JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> < Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> < Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0;
> Expires=Sat, 15-Apr-2017 00:18:44 GMT
> Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0;
> Expires=Sat, 15-Apr-2017 00:18:44 GMT
> < Cache-Control: no-cache
> Cache-Control: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Location:
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> Location:
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> < Content-Type: application/octet-stream
> Content-Type: application/octet-stream
> < Server: Jetty(6.1.26-ibm)
> Server: Jetty(6.1.26-ibm)
> < Content-Length: 0
> Content-Length: 0
> See here the redirection header.
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> This could cause unexpected results.
> The UrlRequestResponse would use the X-Forward headers (even if
> gateway.xforwarded.enabled is false).
> The documentation is very succinct. It seems like the xforwarded.enabled only
> accomplish passing the "Knox" x-Forward-* headers when it is not set to false.
> But there is no documentation on the effect of other servers setting up
> X-Forward header between client and Knox.
> I could even inject an X-Forward-* header and have Knox to redirect to a
> different server than the one original Knox. See my relocation URL
> Location:
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-
> This behavior seems very confusing.
> 1. It should ok to pass multiple X-Forwarded-Host through.
> 2. It is unexpected that Knox should use X-Forward-Host and X-Forwarded-Port
> as the Gateway host and port. e.g. {gateway.host} and {gateway.port} would
> reflect the value of X-Forwarded-Host and X-Forwarded-Port. This doesn't seem
> to leave any other options to rewrite rules which don't want to use
> X-Forwarded-Host.
> 3. The rewrite feature of Gateway doesn't seem to work well with X-Forward*
> feature.
> 4. X-Forward* feature in gateway is not well documented. The extend of the
> documentation is a description of the filter that adds X-Forward headers to
> Knox. We may need to explain whot X-forward headers affect Knox behavior.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
