Jeffrey E Rodriguez created KNOX-924: -----------------------------------------
Summary: 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 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)