You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@knox.apache.org by Jeffrey Rodriguez <je...@gmail.com> on 2017/04/16 00:51:27 UTC

X-forward* header behavior when there are multiple balancers/proxys

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.


Regards,

                 Jeffrey E Rodriguez